Scrum E-Book

Roman Pichler

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2013

Seitenzahl: 248

Beschreibung

Scrum ist ein agiles Projektmanagement-Framework, das sich auf alle Arten der Softwareentwicklung anwenden lässt. Richtig eingesetzt hilft es, Kundenzufriedenheit und Wertschöpfung nachhaltig zu steigern. Roman Pichler vermittelt Ihnen das notwendige Wissen, um Scrum erfolgreich anzuwenden. Er beschreibt das Framework umfassend, systematisch und leicht verständlich. Das Buch wendet sich an Einsteiger in Scrum und agiles Projektmanagement sowie an Fortgeschrittene bzw. an Leser, die sich auf Scrum-Zertifizierungen wie Certified ScrumMaster und Certified Scrum Product Owner vorbereiten.

Leseprobe

Roman Pichler arbeitet als unabhängiger Berater, Trainer und Coach mit den Schwerpunkten Lean und Scrum. Seine Kunden schätzen seine langjährige und vielseitige Erfahrung in der Anwendung von Scrum. Diese beinhaltet die Einführung von Scrum bei Start-ups und bei großen globalen Unternehmen. Mehr Informationen finden Sie unter www.romanpichler.com.

Scrum –Agiles Projektmanagement erfolgreich einsetzen

Roman Pichler

Roman Pichler

[email protected]

Lektorat: Christa Preisendanz

Copy-Editing: Annette Schwarz, Ditzingen

Satz und Herstellung: Frank Heidt

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Druck und Bindung: Koninklijke Wöhrmann B.V., Zutphen, Niederlande

Bibliografische Information Der Deutschen Bibliothek

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

ISBN:

Buch 978-3-89864-478-5

PDF 978-3-89864-849-3

1. Auflage 2008

Copyright © 2008 dpunkt.verlag GmbH

Ringstraße 19

69115 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

Für Melissa

Inhaltsverzeichnis

1        Einleitung

1.1     Was ist Scrum?

1.1.1    Agiles Managementframework

1.1.2    Empirischer Prozess

1.1.3    Kein Wundermittel, sondern harte Arbeit

1.1.4    Scrum und schlankes Management

1.2     Warum Scrum?

1.2.1    Probleme frühzeitig erkennen, Handlungsspielraum sichern

1.3     Warum dieses Buch?

1.4     Mehr Informationen zu Scrum

1.5     Danke

2        Scrum im Überblick

3        Die Rollen

3.1     Product Owner

3.1.1    Die Aufgaben des Product Owner

3.1.2    Der Product Owner als Chief Engineer

3.1.3    Häufiger Fehler: Product Owner nicht verfügbar oder nicht bevollmächtigt

3.2     Team

3.2.1    Individuen und Interaktionen

3.2.2    Teameigenschaften

3.2.3    Teamprozesse: Einer für alle, alle für einen

3.2.4    Teamnormen und Standards

3.2.5    Visueller Arbeitsplatz

3.3     ScrumMaster

3.3.1    Die Aufgaben des ScrumMaster

3.3.2    Der ideale ScrumMaster

3.3.3    Wer ernennt den ScrumMaster?

3.3.4    ScrumMaster und Mitarbeiterführung

3.3.5    Der Wandel der ScrumMaster-Rolle

3.4     Die Rolle des Projektleiters

3.4.1    Scrum und traditionelle Projektmanagementaufgaben

3.4.2    Häufiger Fehler: Der ScrumMaster als Projektleiter

4        Anforderungen

4.1     Klassisches Requirements Engineering und Anforderungsbeschreibung in Scrum

4.1.1    Herkömmliche Verfahren zur Anforderungsbeschreibung

4.1.2    Beschreibung der Anforderungen in Scrum

4.2     Das Product Backlog

4.2.1    Das Product Backlog ist ein lebendes Dokument

4.2.2    Die Einträge sind priorisiert

4.2.3    Die Einträge weisen einen unterschiedlichen Detaillierungsgrad auf

4.2.4    Die Einträge sind abgeschätzt

4.2.5    Die Form des Product Backlog

4.3     Das Produktkonzept

4.3.1    Von der Produktidee zum Product Backlog

4.3.2    Qualitative Marktforschung

4.3.3    Nutzen des Produktkonzepts

4.3.4    Kurz und knapp

4.4     Inkrementelle Innovation

4.4.1    Begriffsklärung

4.4.2    Vorgehensweise

4.4.3    Vorteile

4.5     Das Auffüllen des Product Backlog

4.5.1    Umfang und Vollständigkeit

4.5.2    Unterschiedliche Detaillierungsstufen

4.5.3    Arbeiten mit Themen

4.5.4    Anwendung

4.6     Der Anforderungsworkshop

4.7     Die Priorisierung des Product Backlog

4.7.1    Gründe für die Priorisierung

4.7.2    Kriterien für die Priorisierung

4.7.3    Das Kano-Modell zur Bestimmung von Nutzen

4.7.4    Identifizieren und behandeln von Risiken

4.7.5    Kostenbestimmung

4.7.6    Die Wert-Risiko-Matrix

4.7.7    Die MuSCoW-Priorisierung

4.8     Merkmale guter Anforderungen

4.8.1    Unabhängig

4.8.2    Verhandelbar

4.8.3    Nützlich

4.8.4    Schätzbar

4.8.5    Klein

4.8.6    Testbar

4.9     Benutzergeschichten im Product Backlog

4.9.1    Benutzergeschichten im Überblick

4.9.2    Nutzen

4.9.3    Grenzen

4.10   Anwendungsfälle im Product Backlog

5        Releasemanagement

5.1     Die Releaseplanung im Überblick

5.1.1    Releaseplan? Wir arbeiten doch mit Sprints!

5.1.2    Keine Überstunden und keine Qualitätskompromisse

5.2     Planungsebenen in Scrum

5.2.1    Die Releaseplanung

5.2.2    Die Sprint-Planung

5.2.3    Die Planung des Arbeitstags

5.2.4    Die Beziehung von Releaseplan und Sprint Backlog

5.3     Projektsteuerungsgrößen und Projekterfolg

5.3.1    Steuerungsgrößen

5.3.2    Kriterien für den Projekterfolg richtig kommunizieren

5.4     Releasestrategie

5.4.1    Wertschöpfung in Scrum

5.4.2    Explorationssprints

5.5     Schätzen und Planen

5.5.1    Einführung

5.5.2    Aufwandsbestimmung

5.5.3    Schätzklausur und Planungspoker

5.5.4    Die optimale Sprint-Länge

5.5.5    Die Entwicklungsgeschwindigkeit

5.5.6    Der Releaseplan

5.6     Verfolgen des Projektfortschritts

5.6.1    Einführung

5.6.2    Der Release-Burndown-Bericht

5.6.3    Entwicklungsgeschwindigkeitsbericht

5.6.4    Themenpark

5.7     Optimieren des Projektfortschritts

5.7.1    Vorausschauende Planung

5.7.2    Minimieren von Variation

5.7.3    Eliminieren von Verschwendung

5.7.4    Vermeiden von Überlastung

5.7.5    Ausgewogener Arbeitsanfall

5.8     Projektmanagementwerkzeuge

6        Sprints

6.1     Sprints im Überblick

6.2     Eigenschaften von Sprints

6.2.1    Erstellen eines Produktinkrements

6.2.2    Schutz vor Veränderungen

6.2.3    Verhältnis von Scrum-Besprechungen und Umsetzungsaktivitäten

6.2.4    Wahl eines geeigneten Wochentags für Sprint-Beginn und -Ende

6.3     Vorbereitung der Sprint-Planungssitzung

6.3.1    Identifizieren des Sprint-Ziels

6.3.2    Vorbereiten der Anforderungen

6.3.3    Identifizieren der Teamkapazität

6.3.4    Organisation der Räumlichkeiten

6.4     Die Sprint-Planungssitzung

6.4.1    Ziel

6.4.2    Aufgabenverteilung

6.4.3    Die Planungsschritte im Überblick

6.4.4    Etablierung eines gemeinsames Verständnisses des Sprint-Ziels

6.4.5    Erzielen eines gemeinsames Verständnisses der ausgewählten Anforderung

6.4.6    Identifizieren und Abschätzen der benötigten Aktivitäten

6.4.7    Überprüfen von Kapazität und Leistungsvermögen

6.4.8    Abschluss der Planungssitzung

6.4.9    Typische Fehler

6.5     Das Sprint Backlog

6.5.1    Übersicht

6.5.2    Aktualisierung

6.5.3    Karten und Stellwand

6.6     Die Daily-Scrum-Besprechung

6.6.1    Zeitpunkt, Dauer und Ort

6.6.2    Zielsetzung

6.6.3    Teilnehmer

6.6.4    Ablauf

6.6.5    Vorbereitungsarbeiten

6.6.6    Nützliche Techniken

6.7     Das Sprint-Review

6.7.1    Zeitpunkt, Dauer und Ort

6.7.2    Zielsetzung

6.7.3    Teilnehmer

6.7.4    Ablauf

6.7.5    Vorbereitungsarbeiten

6.7.6    Nützliche Techniken

6.7.7    Typische Fehler

6.8     Die Sprint-Retrospektive

6.8.1    Zeitpunkt, Dauer und Ort

6.8.2    Zielsetzung

6.8.3    Teilnehmer

6.8.4    Ablauf

6.8.5    Vorbereitungsarbeiten

6.8.6    Nützliche Techniken

6.8.7    Typische Fehler

6.9     Frühzeitiges Beenden des Sprint

6.10   Verfolgen des Sprint-Fortschritts

6.10.1  Der Sprint-Burndown-Bericht

6.10.2  Der Hindernisbericht

6.10.3  Der Sprint-Endebericht

6.11   Optimieren des Sprint-Fortschritts

6.11.1  Kontinuierliches Review

6.11.2  Keine halben Sachen

6.11.3  Überlastungen vorbeugen

7        Große und verteilte Projekte

7.1     Größe, Verteilung und Zusammenarbeit

7.1.1    Große Projekte

7.1.2    Verteilte Projekte

7.1.3    Integration und Kommunikation

7.2     Bevor Sie skalieren oder verteilen

7.2.1    Klein anfangen

7.2.2    Klare Ziele

7.2.3    Brook’s Law

7.3     Organisches Wachstum

7.3.1    Zurück zur Natur

7.3.2    Grundlagen schaffen

7.3.3    Langsam wachsen

7.4     Optionen für die Projektorganisation

7.4.1    Product Owner Team

7.4.2    Feature- vs. Komponententeams

7.4.3    Beispiele für die Organisation großer und verteilter Projekte

7.5     Praktiken für große und verteilte Projekte

7.5.1    Anforderungsmanagement

7.5.2    Multiteamplanung

7.5.3    Multiteamkoordination

7.5.4    Projektweite Normen

7.5.5    Infrastruktur

7.5.6    Agile Entwicklungspraktiken

7.6     Tipps für verteilte Projekte

7.6.1    Verteilung entlang der Teamgrenzen

7.6.2    Product Owner und ScrumMaster pro Team und Standort

7.6.3    Schrittweises Verteilen

7.6.4    Regelmäßiger Austausch der Projektmitglieder vor Ort

8        Unternehmensweite Einführung von Scrum

8.1     Unternehmenswandel und Scrum

8.1.1    Gründe für den Wandel

8.1.2    Tragweite und Dauer des Wandels

8.1.3    Merkmale des Wandels

8.2     Einführungsphasen

8.2.1    Pilotphase

8.2.2    Etablierungsphase

8.3     Praktiken zur Einführung von Scrum

8.3.1    Bewusstsein schaffen

8.3.2    Die Geschäftsleitung geht mit gutem Beispiel voran

8.3.3    Die Einführung von Scrum als Scrum-Projekt managen

8.3.4    Eine glaubhafte Vision entwickeln

8.3.5    Oft und richtig kommunizieren

8.3.6    Mitarbeiter bevollmächtigen

8.3.7    Veränderungen schrittweise vornehmen

8.3.8    Nach Perfektion streben

Anhang

Glossar

Literaturverzeichnis

Index

Geleitwort

The only question regarding Roman Pichler’s new book on Scrum is, »where is the English version?« I’ve known and worked with Roman for years with Scrum, so the book is full of practical advice. This book not only faithfully documents Scrum, it also provides a state of the art view of the most current thinking about using Scrum. More information about maintaining the Product Backlog, planning and managing releases, the retrospective, and people management reflect sound practices to know and employ. Since the use of Scrum depends on common sense, these are often presented severally. This book is a solid addition to the compendium of books to aid the Scrum practitioner and ScrumMaster.

Ken SchwaberScrum Evangelist and AuthorBoston, August 2007

1 Einleitung

1.1 Was ist Scrum?

1.1.1 Agiles Managementframework

Scrum [skr∧m] ist ein agiles Managementframework zur Entwicklung von Software, das aus wenigen klaren Regeln besteht. Diese beinhalten die Anwendung der drei Rollen Product Owner, Team und ScrumMaster, die Verwendung eines priorisierten Product Backlog sowie das Erstellen von Produktinkrementen innerhalb kurzer Arbeitszyklen, die Sprints genannt werden. Scrum lässt sich auf alle Arten der Softwareentwicklung anwenden: Software als eigenständiges Produkt und Software als Bestandteil eines Produkts, Software als unternehmensinterne Lösung oder Software, die im Auftrag eines Kunden entwickelt wird; Software, die neu entwickelt, und Software, die gewartet wird.

Als agiles Framework verkörpert Scrum die Werte des Agilen Manifests [Beck et al. 2001]. Dieses stellt den Menschen in den Mittelpunkt der Softwareentwicklung (individuals and interactions, collaboration). Schließlich entsteht Software nur durch die Interaktion und Kollaboration von Menschen. Scrum ist nicht technologie- oder toolorientiert, sondern fordert und fördert die enge Zusammenarbeit der Beteiligten. Das Agile Manifest formuliert außerdem die Optimierung von Kundenzufriedenheit und Wertschöpfung als Ziel der Softwareentwicklung (working software, collaboration, responding to change). Für kommerzielle Softwareprojekte zählt letztendlich, ob die wirtschaftlichen Ziele des Projekts erreicht wurden, ohne dabei Raubbau an den Mitarbeitern oder zukünftigen Softwareversionen und damit Kundenzufriedenheit und Wertschöpfung zu treiben. In Scrum ist der Product Owner für die Erreichung der wirtschaftlichen Ziele des Projekts verantwortlich und steuert dieses durch das priorisierte Product Backlog und den Releaseplan.

Scrum und Rugby

Der Begriff Scrum stammt aus dem Rugby und wird auf Deutsch als »Gedränge« übersetzt. Vereinfacht lässt sich der Spielzug folgendermaßen beschreiben: Jeweils acht Spieler der beiden Mannschaften formen das Gedränge. Beide Spielergruppen stehen sich eng umschlungen und nach vorne gebeugt gegenüber. Die vordersten drei Spieler verkeilen Kopf und Schultern. Alle Spieler drücken nun nach vorne. Ein Spieler außerhalb des Gedränges, der sog. Gedrängehalb der ballführenden Mannschaft, wirft den Ball seitlich in das Gedränge. Seine Mitspieler im Gedränge müssen den Ball mit den Füßen nach hinten schieben. Erst wenn der Ball das Gedränge verlassen hat, darf er wieder aufgenommen und ein Angriff eingeleitet werden. Das Gedränge ist ein komplizierter Spielzug, der sorgsam einstudiert und orchestriert werden muss. Er verlangt eine disziplinierte Teamarbeit.

1.1.2 Empirischer Prozess

Scrum ist ein empirischer Prozess. Arbeitsweise und Produkt werden regelmäßig begutachtet und angepasst (sog. inspect and adapt). Am Ende eines jeden Sprint beurteilt der Product Owner die Angemessenheit der erzielten Ergebnisse, und das Team reflektiert über seine Zusammenarbeit und die Anwendung des Prozesses. So lernt das Projekt von Sprint zu Sprint dazu und kann sich kontinuierlich verbessern. Scrum ist keine herkömmliche Methodologie und keine Komplettlösung. Scrum schreibt nicht detailliert vor, was wann zu tun ist, sondern fördert die Kreativität der Mitarbeiter. Daher beinhaltet Scrum auch keine Verfahrensanweisungen oder Templates: Soweit diese hilfreich sind, müssen Sie sie für Ihr Projekt und Ihre Organisation selbst erarbeiten.

1.1.3 Kein Wundermittel, sondern harte Arbeit

Scrum ist kein Wundermittel, das, einmal in eine Organisation eingeführt, quasi von selbst alles besser werden lässt. Im Gegenteil: Oft sind die ersten Sprints für Projektmitarbeiter und Management schwierig. Hindernisse und Probleme treten auf und müssen beseitigt werden, um zielgerichtet weiterarbeiten zu können. Dabei müssen alle Beteiligten nicht nur die neuen Spielregeln erlernen, sondern auch alte Angewohnheiten ablegen. Diese beinhalten das Zuweisen von Aufgaben an Mitarbeiter und das Erstellen qualitativ minderwertiger Software. Das erfolgreiche Anwenden von Scrum ist also ein Lernprozess, der Zeit und Geduld benötigt und neben den Teammitgliedern, dem ScrumMaster und dem Product Owner auch das Management betrifft. Seien Sie dabei auf der Hut: Oft ist es verlockend, nicht die eigenen Arbeitspraktiken, sondern Scrum zu ändern.

1.1.4 Scrum und schlankes Management

Die Geburtsstunde von Scrum fällt in das Jahr 1993: In diesem Jahr wurde das erste Scrum-Projekt durchgeführt [Sutherland 2004]. Beeinflusst wurde Scrum von Anfang an von neuen, innovativen Wegen in der Produktentwicklung, wie sie insbesondere von japanischen Unternehmen pilotiert wurden [Takeuchi&Nonaka 1986]. Diese neue Form des Managements und der Produktentwicklung wird heute als »schlank« (lean) bezeichnet [Womack&Jones 1996]. Besonders Toyota hat bei der Entwicklung schlanker Entwicklungsprozesse eine führende Rolle eingenommen [Liker 2003]. Ich verweise in diesem Buch auf erprobte Vorgehensweisen der schlanken Produktentwicklung [Morgan&Liker 2006, Ward 2007] und der schlanken Softwareentwicklung [Poppendieck 2003], wo diese Scrum-Praktiken erklären oder sinnvoll ergänzen. Scrum ist übrigens ein schlanker Prozess, der ein Ziehsystem (pull) einsetzt und Überlastungen systematisch vermeidet.

1.2 Warum Scrum?

1.2.1 Probleme frühzeitig erkennen, Handlungsspielraum sichern

Softwareentwicklung ist schwierig und herausfordernd. An dieser Tatsache ändert auch Scrum nichts. Denn das Wesen der Softwareentwicklung ist Innovation und Kreativität: Jedes Softwareentwicklungsprojekt befriedigt neue Kundenbedürfnisse. Um Bedürfnisse aufzudecken, zu verstehen und die richtige Lösung zu entwickeln, benötigen wir eine ordentliche Portion Kreativität. Dies fällt vielen Organisationen nicht leicht: Oft scheitern Softwareentwicklungsprojekte oder liefern Ergebnisse, die weder Kunden zufriedenstellen noch die angestrebten wirtschaftlichen Ziele erreichen. Organisationen und Projekte verfallen dabei in einen Teufelskreislauf:

Abb. 1–1 Ein Teufelskreislauf, Quelle: [Ward 2007]

Sind die Ziele in Gefahr, so bitten wir häufig die Projektmitarbeiter länger zu arbeiten und fügen neue Mitarbeiter zum Projekt hinzu. Bedingt durch Hektik und Stress, längere Arbeitszeiten und schlecht eingearbeitete Projektmitglieder sinken die Softwarequalität und die Moral der Mitarbeiter. Dies veranlasst das Management, mehr Kontrollen einzuführen, die die Entwicklung weiter verlangsamen.

Softwareentwicklungsprojekte weisen eine suboptimale Arbeitsorganisation nicht etwa deswegen auf, weil Management und Mitarbeiter nicht guten Willens sind. Das zentrale Problem traditioneller Vorgehensweisen besteht darin, dass wir frühzeitig versuchen, alle Eventualitäten und Arbeitsdetails zu antizipieren und einzuplanen, um anschließend unseren Plan auszuführen. Gleichzeitig erhalten wir erst spät im Projekt Rückmeldung über den tatsächlichen Fortschritt, meist erst dann, wenn die Software integriert und getestet wird. In Scrum führen wir alle Softwareentwicklungsaktivitäten innerhalb eines Sprint aus. So bekommen wir bereits nach wenigen Wochen Rückmeldung über den Fortschritt und etwaige Probleme und Hindernisse. Die Projektplanung fußt auf dem tatsächlichen Fortschritt des Projekts. Dabei gehen wir vor, wie in Abbildung 1–2 dargestellt.

Abb. 1–2 Der Scrum-Kreislauf

Durch die Verwendung von kurzen Arbeitszyklen, an deren Ende ein Mehrwert entstanden sein muss, werden Probleme in Scrum frühzeitig offensichtlich. Wir haben so die Möglichkeit, rechtzeitig die Ursache des Übels aufzufinden, Lösungsoptionen zu entwickeln und die richtigen Maßnahmen zu ergreifen. Das frühe Auffinden von Problemen eröffnet uns einen größeren Handlungsspielraum und Flexibilität. Finden wir Probleme erst spät im Projekt, so sind viele Entscheidungen bereits gefällt und wir meist zur Schadensbegrenzung verdammt. Ursachenanalyse zu betreiben und die richtigen Verbesserungsmaßnahmen zu ergreifen, ist dabei kein Fingerschlecken, sondern harte Arbeit.

Die Mitarbeiter, Kunden und das liebe Geld

Wenn Sie Scrum konsequent einsetzen, so sollten Sie in den nachfolgend aufgeführten Bereichen positive Veränderungen erfahren.

Mitarbeiterzufriedenheit

Die Mitarbeiterzufriedenheit steigt bedingt durch Maßnahmen wie Bevollmächtigung und Selbstorganisation. Der Großteil der Scrum-Projektmitarbeiter bei Yahoo! beispielsweise beantwortete in einer Umfrage die Frage nach Verbesserung der Teammoral positiv [Deemer&Benefield 2006].

Kundenzufriedenheit

Durch die enge Zusammenarbeit mit Kunden und deren Einbeziehung beispielsweise in Anforderungsworkshops und Sprint-Reviews stellen wir sicher, dass die resultierende Software die Kundenbedürfnisse befriedigt.

Das liebe Geld

Softwareentwicklungsprojekte existieren, um einen wirtschaftlichen Nutzen zu erzielen. Scrum hilft, diesen durch folgende positive Auswirkungen zu erreichen oder zu übertreffen:

Time to market

Scrum ermöglicht durch eine strikte Priorisierung der Anforderungen, durch die Vermeidung von Fehlleistungen und Überlastung, Software frühzeitig auszuliefern.

Qualität

Scrum richtig angewandt führt zu einer Verbesserung der Softwarequalität. Ohne adäquate Qualität lassen sich auslieferbare Produktinkremente nicht innerhalb weniger Wochen erstellen.

Produktivität

Durch enge Kollaboration, Selbstorganisation, durch Bevollmächtigung, durch das Vermeiden von Fehlleistungen und das Fokussieren auf die wichtigsten Anforderungen steigert Scrum die Produktivität. Yahoo! stellte beispielsweise eine deutliche Verbesserung der Produktivität beim Einsatz von Scrum fest [Deemer&Benefield 2006].

1.3 Warum dieses Buch?

Das vorliegende Buch bietet eine systematische und umfassende Beschreibung von Scrum und ergänzt die existierenden Bücher. Meine Intention ist nicht, dem Leser eine detaillierte Anleitung zur Anwendung von Scrum oder gar eine Scrum-Bibel zur Verfügung zu stellen. Dies widerspräche dem Wesen von Scrum als einem empirischen Prozess, der auf die spezifischen Bedürfnisse eines Projekts angewandt werden muss und sich weiterentwickelt. Folgen Sie den Empfehlungen dieses Buchs daher nicht blind, sondern reflektieren Sie über Ihre Situation und passen Sie ggf. die Empfehlungen entsprechend an! Das Buch behandelt einführende und fortgeschrittene Themen. Stellen Sie sicher, dass Sie die Grundlagen verstanden haben, bevor Sie weiterführende Kapitel wie »Große und verteilte Projekte« lesen.

1.4 Mehr Informationen zu Scrum

Weitere Informationen zu Scrum sowie Scrum-Schulungen wie Certified Scrum-Master (CSM) und Certified Scrum Product Owner (CSPO) finden Sie auf der Webseite der Scrum Alliance, www.scrumalliance.org.

1.5 Danke

Ohne die Unterstützung und Mitarbeit vieler Menschen wäre dieses Buch nie möglich gewesen. Besonders bedanken möchte ich mich bei Ken Schwaber, Mike Cohn, Jutta Eckstein, Preston Smith und Nancy van Schooenderwoert, ohne deren Unterstützung und Ermutigung ich dieses Buch wahrscheinlich nie geschrieben hätte. Jutta Eckstein ist quasi die Patentante des Buchs, da sie die Zusammenarbeit zwischen dem dpunkt.verlag und mir initiiert hat. Außerdem möchte ich mich ganz herzlich bei meinen Reviewern bedanken: Jutta Eckstein, Stefan Roock, Sabine Canditt, Jens Coldewey, Bernd Oestereich, Nicolas Arnold und Jiri Lundak.

2 Scrum im Überblick

Scrum besteht aus wenigen klaren Regeln. Damit Scrum funktioniert, müssen diese konsequent und diszipliniert angewandt werden, auch wenn dies anfangs nicht leichtfällt. Scrum schafft ein hohes Maß an Transparenz: Alle Aktivitäten, die zur Erstellung der Software notwendig sind, werden innerhalb weniger Wochen ausgeführt. So wird der tatsächliche Projektfortschritt schnell sichtbar.

Abbildung 2–1 gibt einen Überblick über die wesentlichen Elemente von Scrum, vgl. [Schwaber&Beedle 2001]. Diese werden in den nachfolgenden Kapiteln ausführlich beschrieben.

Abb. 2–1 Scrum im Überblick

Wie Abbildung 2–1 zeigt, besteht ein Scrum-Projekt aus einer Reihe kurzer Arbeitszyklen, die Sprints genannt werden. Jeder Zyklus wandelt Anforderungen aus dem Product Backlog in ein auslieferbares Produktinkrement um, also in lauffähige, getestete und dokumentierte Software. Die Dauer eines Sprint beträgt maximal 30 Tage. Jeder Sprint endet zum vereinbarten Termin (timeboxing). Bevor ein Scrum-Projekt starten kann, müssen Product Owner, Team und ScrumMaster einsatzbereit sein. Zudem muss das Product Backlog initial gefüllt sein. Dieses legt fest, welche Anforderungen und Arbeitsergebnisse erbracht werden müssen, um das Projektziel zu erreichen. Alle Anforderungen sind priorisiert.

Zu Beginn jedes Sprint führen wir eine Sprint-Planungssitzung durch, in der das Team Anforderungen auswählt und das Sprint Backlog erstellt. Dieses beschreibt alle Aktivitäten zur Umsetzung der Anforderungen in ein Produktinkrement. Anschließend startet das Team mit der Realisierung der Anforderungen. Jeden Tag am selben Ort zur selben Zeit findet eine kurze Besprechung statt, die Daily Scrum genannt wird. Diese ermöglicht dem Team, die anstehende Arbeit zu koordinieren und Hindernisse systematisch zu identifizieren. Am Ende des Sprint werden die entstandenen Arbeitsergebnisse vom Product Owner im Sprint-Review überprüft und abgenommen. Partiell fertiggestellte oder defekte Arbeitsergebnisse gelten dabei als nicht erledigt. Im Anschluss an das Sprint-Review findet die Sprint-Retrospektive statt, in der das Team über seine Zusammenarbeit reflektiert und Verbesserungsmaßnahmen ableitet. Die Verbesserungsmaßnahmen werden anschließend in die nächste Sprint-Planungssitzung eingebracht.

3 Die Rollen

Scrum kennt drei Rollen: Product Owner, Team und ScrumMaster. Alle drei Rollen müssen adäquat besetzt sein und eng zusammenarbeiten, um ein Scrum-Projekt zum Erfolg zu führen. Schließlich stellt das Agile Manifest nicht umsonst fest, dass Individuen und Interaktionen wichtiger sind als Prozesse und Werkzeuge [Beck et al. 2001]. Typischerweise arbeitet ein Product Owner mit einem Team zusammen. Jedes Team hat einen eigenen ScrumMaster, und jeder Scrum-Master betreut ein Team.

Die drei Rollen weisen die folgenden Verantwortlichkeiten auf: Der Product Owner entscheidet, welche Anforderungen für eine Version umgesetzt werden und wann die Software ausgeliefert wird. Das Team führt die Arbeit aus, entscheidet, wie viele Anforderungen es in einem Sprint verlässlich in ein Produktinkrement umsetzen kann, und organisiert seine Arbeit selbstständig. Der ScrumMaster hilft allen Beteiligten, Scrum richtig anzuwenden, und unterstützt das Team dabei, seine Produktivität kontinuierlich zu verbessern. Die Anwendung der Rollen hat Konsequenzen für das Produktmanagement und die Entwicklung: Beide Partner müssen ihren Beitrag dazu leisten, dass Scrum richtig gelebt wird, und die hierfür notwendigen Veränderungen vornehmen.

Unterschätzen Sie nicht, wie wichtig das richtige Verständnis und die richtige Besetzung der Rollen für den erfolgreichen Einsatz von Scrum sind. Ich beobachte bei Scrum-Projekten in Schwierigkeiten immer wieder, dass die Rollen nicht richtig verstanden und nicht richtig besetzt sind.

3.1 Product Owner

Der Product Owner in Scrum repräsentiert die Endkundenbedürfnisse, steuert die Softwareentwicklung und arbeitet mit dem Team über den gesamten Projektverlauf eng zusammen. Die Rolle ist also weit mehr als die eines traditionellen Programm-, Produkt- oder Projektmanagers. Die Rolle vereint Produkt- und Projektmanagementaufgaben in sich und ist zugleich fest in die Softwareentwicklung integriert. Der Product Owner nimmt in Scrum eine zentrale Stellung ein. Er beeinflusst den Erfolg eines Scrum-Projekts entscheidend und ist für diesen verantwortlich.

Scrum beendet ineffektive Arbeitspraktiken: Anforderungen werden nicht mehr zu Beginn des Projekts komplett aufgeschrieben, eingefroren und an die Entwicklung übergeben. Die Umsetzung des Projekts wird nicht länger an einen Projektleiter delegiert. Als Product Owner bestimmen Sie, wohin die Reise geht, und nehmen auf dem Fahrersitz Platz.

Die Arbeit als Product Owner ist im Regelfall eine Vollzeitaufgabe. Dies ist insbesondere dann der Fall, wenn es sich um ein innovatives oder komplexes Projekt handelt. Seien Sie sich bewusst: Der Projektfortschritt leidet, wenn der Product Owner für seine Aufgaben nicht qualifiziert ist oder für diese nicht genügend Zeit aufwenden kann. Die Besetzung der Product-Owner-Rolle ist abhängig von der Projektart und der Größe sowie der Struktur des Projekts. Häufig wird die Rolle mit einem Produktmanager oder Marketingmitarbeiter gefüllt.

3.1.1 Die Aufgaben des Product Owner

Anforderungsbeschreibung und -management

Der Product Owner ist für das Erfassen der Kundenbedürfnisse und die Beschreibung der Anforderungen verantwortlich. Dies beinhaltet das Erstellen des Produktkonzepts und des Product Backlog. Der Product Owner bearbeitet das Product Backlog kontinuierlich: Er fügt neue Anforderungen ein und entfernt existierende. Er verfeinert und priorisiert Anforderungen. Damit der Product Owner die Bedürfnisse der Kunden und Anwender beschreiben und dem Team kommunizieren kann, muss er diese genau kennen und in der Lage sein, Mehrwert aus Kundensicht zu bestimmen. Eine enge und regelmäßige Abstimmung mit den Kunden und Anwendern sowie anderen Interessenvertretern ist hierzu notwendig, beispielsweise in Form von gemeinsamen Workshops zur Identifizierung und Beschreibung von Anforderungen.

Releasemanagement und Return on Investment

Der Product Owner ist in Scrum für das Erreichen der Projektziele und damit für den Erfolg des Projekts (return on investment, ROI) verantwortlich. Er allein entscheidet über Auslieferungszeitpunkt, Funktionalität und Kosten der Softwareversion. Der Product Owner erstellt und aktualisiert den Releaseplan und die Releaseberichte. Anders als traditionelle Produktmanager delegiert er die Leitung des Entwicklungsprojekts also nicht an einen Projektmanager oder Teamleiter. Im Gegenteil: Der Product Owner führt wichtige Projektmanagementaufgaben selbst aus. Dabei steuert er die Entwicklung über die Formulierung von Anforderungen und deren Priorisierung im Product Backlog.

Der Product Owner bei Yahoo!

Yahoo! bezeichnet den Product Owner als »single wringable neck«. Auch wenn diese Titulierung schroff klingt, so macht sie doch deutlich, dass der Product Owner für den Projekterfolg verantwortlich ist.

Enge Zusammenarbeit mit dem Team

Der Product Owner arbeitet während der gesamten Projektdauer eng mit dem Team zusammen. Er hilft dem Team, die Kundenbedürfnisse und Anforderungen zu verstehen und diese in Produktinkremente umzusetzen, indem er es mit detaillierten Anforderungen versorgt und die entstandenen Arbeitsergebnisse überprüft. Der Product Owner schlägt also die Brücke zwischen den Endkunden und der Softwareentwicklung. Zu den operativen Aufgaben des Product Owner zählen die Detaillierung und Verfeinerung der im nächsten Sprint umzusetzenden Anforderungen, die Teilnahme an allen Scrum-Besprechungen sowie die Überprüfung und Abnahme der in einem Sprint erzielten Arbeitsergebnisse.

Als Product Owner sollten Sie ausreichend Zeit mit dem Team verbringen und zu festen Zeiten jeden Tag für mindestens eine Stunde mit dem Team arbeiten, z.B. im Anschluss an die Daily Scrum. So sind Sie verfügbar, können Fragen schnell klären und Feedback zu Arbeitsergebnissen bereits im laufenden Sprint geben.

Empirisches Management und »Geh und sieh selbst«

Sich selbst ein Bild vom aktuellen Arbeitsgeschehen vor Ort zu verschaffen, bezeichnen [Schwaber&Beedle 2001] als empirisches Management. In der schlanken Produktenwicklung wird dies »Geh und sieh selbst« (japanisch genchi genbutsu) genannt und spielt als Managementprinzip eine zentrale Rolle [Liker 2003, Ward 2007]. Angewandt auf den Product Owner bedeutet dies eine enge Zusammenarbeit mit dem Team und das regelmäßige Begutachten von Arbeitsergebnissen. »Geh und sieh selbst« wird übrigens von dem Managementprinzip »Respekt« ergänzt: Der Product Owner sollte stets der Arbeit des Teams Respekt zollen und konstruktives Feedback geben, selbst wenn er die Arbeitsergebnisse nicht für gut befindet.

Stakeholder-Management

Der Product Owner bindet die verschiedenen Interessengruppen inklusive den Endkunden ein und erfasst ihre Bedürfnisse regelmäßig. Dies ist notwendig, um alle Anforderungen zu identifizieren, die für den erfolgreichen Einsatz der Software beim Kunden notwendig sind. Zu den Interessengruppen zählen beispielsweise Marketing, Vertrieb, Service und IT. Der Product Owner bündelt und filtert also die verschiedenen Anforderungen. Eine ideale Form der Einbindung ist beispielsweise die Einladung der Interessenvertreter zu einem Workshop zur Anforderungsbeschreibung und zum Sprint-Review. So können Endkunden und Interessenvertreter direkt mit Teammitgliedern interagieren, Feedback geben und ihre Bedürfnisse erläutern.

Oft ist es schwer, als Product Owner von Anfang an alle Aufgaben zu erfüllen. Am wichtigsten ist es nach meiner Erfahrung, dass der Product Owner die Endkundenbedürfnisse versteht und diese an das Team klar kommunizieren kann. Das Ausüben der anderen Aufgaben lässt sich im Regelfall relativ schnell erlernen.

3.1.2 Der Product Owner als Chief Engineer

In der schlanken Produktenwicklung wird die Rolle des Product Owner bereits seit Jahrzehnten erfolgreich eingesetzt. Der schlanke Product Owner ist dabei ein Hybrid aus Produktmanager, Projektleiter und Chefarchitekt. Bei Toyota, einem Pionier schlanker Prozesse, wird diese Rolle als Chief Engineer bezeichnet [Morgan&Liker 2006, Ward 2007]. Der Chief Engineer entscheidet über die Leistungsmerkmale eines Fahrzeugs und ist verantwortlich für den Projektplan und die Projektsteuerung. Er verfügt über ein fundiertes technisches Verständnis und fällt übergreifende Architekturentscheidungen. Der Chief Engineer wird vom Topmanagement beauftragt, ist innerhalb der Entwicklung höchst angesehen und betreut ein Produkt meist über mehrere Versionen.

Die Rolle des Chief Engineer ist einer der Eckpfeiler eines schlanken Entwicklungssystems [Ward 2007]. Sie ist so wertvoll und mächtig, da sie die Rollen Produktmanager, Projektleiter und Chefarchitekt in einer Person vereint. So werden nicht nur Übergaben, Wartezeiten und Flüsterposteffekte vermieden, der Chief Engineer agiert zugleich als Wertstrommanager: Er hilft, die zur Entwicklung des Produkts notwendigen Aktivitäten zu optimieren, nicht wertschöpfende Aktivitäten zu eliminieren, unnötige Variationen der Aktivitäten und eine Überlastung der Mitarbeiter zu vermeiden. So entsteht ein optimierter, ausgeglichener Arbeitsfluss, siehe Abschnitt 5.7.

Um Mitarbeiter zum Product Owner auszubilden, der alle Aufgaben adäquat ausführen kann, benötigen die meisten Organisationen Zeit. Als Übergangslösung kann es daher insbesondere für komplexe oder große Projekte sinnvoll sein, ein Product Owner Team zu bilden, siehe Abschnitt 7.4.1.

3.1.3 Häufiger Fehler: Product Owner nicht verfügbar oder nicht bevollmächtigt

Obwohl der Product Owner den Erfolg eines Scrum-Projekts maßgeblich beeinflusst, erlebe ich es leider häufig, dass Product Owner überlastet oder nicht bevollmächtigt sind, die notwendigen Entscheidungen zu treffen. Dies führt dazu, dass der Mitarbeiter seine Aufgaben nicht adäquat wahrnehmen kann. Meist leiden insbesondere die Vorbereitung der Sprint-Planungssitzung und die Zusammenarbeit mit dem Team. Entscheidungen werden nicht schnell getroffen, und Verzögerungen treten auf. Am besten bestehen Sie als Product Owner darauf, dass Sie mindestens die Hälfte Ihrer Arbeitszeit für die Ausübung der Rolle aufwenden können und dass das Management Sie unterstützt und bevollmächtigt.

3.2 Team

Das Team führt alle Arbeiten aus, die zur Umsetzung der Anforderungen in auslieferbare Produktinkremente notwendig sind. Die Softwareentwicklung ist in Scrum somit teambasiert. Softwareentwickler, Architekten, Tester, Datenbankspezialisten und andere Rollen arbeiten eng zusammen und erstellen Arbeitsergebnisse gemeinschaftlich.

3.2.1 Individuen und Interaktionen

Bevor wir die Eigenschaften von Scrum-Teams diskutieren, sollten wir uns bewusst machen: Entscheidend ist, dass die richtigen Mitarbeiter im Team mitarbeiten. Das heißt, Mitarbeiter, die über das relevante Wissen und die notwendigen Fähigkeiten verfügen und produktiv zusammenarbeiten können. Scrum-Teams, für die dies nicht gilt, sind meist wenig produktiv.

Um sicherzustellen, dass die richtigen Mitarbeiter Teil des Teams sind, ist es sinnvoll, die Mitarbeiter mitbestimmen zu lassen, an welchen Projekten sie mitarbeiten möchten [Schwaber 2007]. Google ermutigt beispielsweise Entwickler, sich für interessante Projekte selbst zu nominieren [Poppendieck 2006]. Dies ist eine Variante von Selbstselektion: Mitarbeiter beeinflussen, an welchen Projekten sie mitarbeiten, anstelle dass »Ressourcen« Projekten zugewiesen werden.

3.2.2 Teameigenschaften

Bevollmächtigt

Ein Scrum-Team ist bevollmächtigt (empowered): Das Team entscheidet allein, wie viele Anforderungen es innerhalb des nächsten Sprint in ein Produktinkrement umwandeln kann. Somit legt das Team fest, wie viel Arbeit es im jeweiligen Sprint zuverlässig erledigen kann. Zudem entscheidet es, welche Arbeitsschritte notwendig sind und wie es seine Arbeit organisiert. Ein bevollmächtigtes Team muss auch in schwierigen Situationen in der Lage sein, nein zu vielen Anforderungen zu sagen.

Bevollmächtigung verlangt vom Management Vertrauen in die Fähigkeit des Teams sowie die Delegation von Entscheidungsbefugnis. Traditionell weisen Vorgesetzte ihren Mitarbeitern meist Aufgaben zu, deren Ausführung sie anschließend überprüfen (sog. command and control). Dies veranschaulicht Abbildung 3–1.

Abb. 3–1 Traditionelles Management, Quelle: [Ward 2007]

Traditionelles Management trennt die Übernahme von Verantwortung und das Ausführen der Arbeit [Ward 2007]. Der Vorgesetzte ist oft vom Entwicklungsgeschehen isoliert und trägt selbst nicht unmittelbar zur Wertschöpfung bei. Nicht selten genießen Manager den zweifelhaften Luxus eines eigenen Büros, das eine räumliche Trennung vom eigentlichen Arbeitsgeschehen bedeutet. Vorgesetzte sind so gezwungen, sich über den aktuellen Arbeitsstand durch das Lesen von Berichten oder das Gespräch mit einzelnen Mitarbeitern zu informieren. Zugleich übernehmen Mitarbeiter oft nicht die Verantwortung für die Konsequenzen ihres Handelns: Schließlich befolgen sie ja die Vorgaben ihres Vorgesetzten.

Bevollmächtigung hingegen vereint Ursache und Wirkung: Das Team wählt die umzusetzenden Anforderungen zu Beginn eines jeden Sprints aus und steht zugleich in der Pflicht, die Auswahl zuverlässig in ein Produktinkrement umzusetzen. Dies illustriert Abbildung 3–2.

Abb. 3–2 Das Zusammenspiel von Product Owner und Team

Durch die Verwendung kurzer Arbeitszyklen und das regelmäßige Feedback des Product Owner lernt das Team, seine Verpflichtung immer besser zu erfüllen.

Autonom

Das Scrum-Team ist autonom: Das Team muss in der Lage sein, das Sprint-Ziel ohne wesentliche externe Abhängigkeiten zu erreichen. Ansonsten fällt es dem Team schwer, eine echte Verpflichtung zur Erreichung des Sprint-Ziels abzugeben und auslieferbare Produktinkremente zuverlässig am Ende jeden Sprints zu erstellen. Ein Indiz dafür, dass das Team nicht autonom ist, ist das regelmäßige Auftreten von Aufgaben im Sprint Backlog, die von Mitarbeitern außerhalb des Teams ausgeführt werden müssen, um das Sprint-Ziel zu erreichen. Oftmals verfügt das Team nicht über alle notwendigen Funktionen und ist damit auch nicht ausreichend interdisziplinär besetzt.

Interdisziplinär besetzt

Das Scrum-Team ist interdisziplinär besetzt: Alle Rollen, die zur Umsetzung der Projekt- und Sprint-Ziele benötigt werden, müssen im Team vertreten sein. Beispiele hierfür sind Architekt, Entwickler, Tester, Dokumentationsexperte, User Interface Designer, Datenbankexperte, Konfigurationsmanager. Damit ein interdisziplinäres Team gut zusammenarbeitet, ist es notwendig, dass die Teammitglieder über gemeinsames Softwareentwicklungswissen verfügen und verschiedene Aufgaben im Team wahrnehmen können (cross-skilling). Oft spricht man bei Mitarbeitern agiler Teams auch von generalistischen Spezialisten (generalist-specialist): Obwohl Mitarbeiter über wertvolles Spezialwissen verfügen, sind sie in der Lage, effektiv zusammenarbeiten und ggf. die Arbeit eines anderen Teammitglieds zu übernehmen. Ein engstirniges Rollenverständnis nach dem Motto »Ich bin Architekt, und Programmieraufgaben übernehme ich nicht« ist mit Scrum unverträglich. Das Team verpflichtet sich kollektiv zur Umsetzung des Sprint-Ziels. Alle Teammitglieder müssen daher eng zusammenarbeiten und sich gegenseitig unterstützen.

Interdisziplinäre Teams und Mitarbeiterqualifikation

In der schlanken Produktentwicklung werden ebenfalls interdisziplinäre Teams eingesetzt, die sich weitgehend selbst organisieren [Morgan&Liker 2006, Ward 2007]. Zusätzlich legen Unternehmen wie Google oder Toyota großen Wert auf die Qualifikation der Mitarbeiter. Oft spricht man in diesem Zusammenhang von engineering excellence, also von herausragenden technischen Fähigkeiten der Mitarbeiter, die gezielt weiterentwickelt werden.

Selbstorganisiert

Das Scrum-Team organisiert sich selbst: Die Mitglieder des Teams entscheiden gemeinsam, welche Aufgaben notwendig sind, um das Sprint-Ziel zu erreichen, und wer welche Aufgaben übernimmt. Selbstorganisierte Teams benötigen somit keinen Teamleiter oder Manager. Selbstorganisation in Scrum ist diszipliniert: Das Sprint Backlog, der Sprint-Burndown-Bericht und die Daily-Scrum-Besprechung bilden die Grundlagen der Selbstorganisation.

Die Arbeit selbst zu organisieren ist für die meisten Teams ein Lernprozess, bei dem der ScrumMaster das Team unterstützt und führt. Dies schließt auch das Erlernen von konstruktivem Umgang mit Konflikten sowie die Anwendung kollaborativer Entscheidungsverfahren ein, siehe [Kaner et al. 1996