Scrum: Agiles Projektmanagement erfolgreich einsetzen
3.5/5
()
About this ebook
Read more from Roman Pichler
Leadership im Produktmanagement: Wie Sie Stakeholder und Entwicklungsteams effektiv führen Rating: 0 out of 5 stars0 ratingsAgiles Produktmanagement mit Scrum: Erfolgreich als Product Owner arbeiten Rating: 3 out of 5 stars3/5Strategisches Produktmanagement: Produktstrategien und Roadmaps für digitale Produkte und agile Teams Rating: 0 out of 5 stars0 ratings
Related to Scrum
Related ebooks
Modellbasiertes Requirements Engineering: Von der Anforderung zum ausführbaren Testfall Rating: 0 out of 5 stars0 ratingsProjektmanagement für Anfänger: Grundlagen, -begriffe und Tools Rating: 0 out of 5 stars0 ratingsGrundlagen des Projektmanagements: Methoden, Techniken und Tools für Projektleiter Rating: 0 out of 5 stars0 ratingsAgiles Projektmanagement: Scrum für Einsteiger Rating: 0 out of 5 stars0 ratingsProjektmanagement: Kein Buch mit sieben Siegeln Rating: 0 out of 5 stars0 ratingsPraxishandbuch Prozessmanagement: Das Standardwerk auf Basis des BPM Framework ibo-Prozessfenster® Rating: 0 out of 5 stars0 ratingsProjekte und Prozesse managen: Methodische Kompetenzen für Führungskräfte in der Verwaltung Rating: 0 out of 5 stars0 ratingsProjektmanagement von Online-Projekten Rating: 0 out of 5 stars0 ratingsProjektmanagement: 100 Fragen und Antworten Rating: 0 out of 5 stars0 ratingsMit dem Nexus™ Framework Scrum skalieren: Kontinuierliche Bereitstellung eines integrierten Produkts mit mehreren Scrum-Teams Rating: 0 out of 5 stars0 ratingsGanzheitliches Projektmanagement Rating: 0 out of 5 stars0 ratingsProjektmanagement: Grundlagen, Methoden und Techniken Rating: 0 out of 5 stars0 ratingsAgiles Projektmanagement und Scrum: Praxishandbuch Agiles Arbeiten Rating: 0 out of 5 stars0 ratingsScrum. Schnelleinstieg (3. Aufl.) Rating: 0 out of 5 stars0 ratingsScrum im Einkauf: Agiles arbeiten mit Scrum im Einkauf Rating: 0 out of 5 stars0 ratingsKanban: Der agile Klassiker einfach erklärt Rating: 0 out of 5 stars0 ratingsGeschichten vom Scrum: Von Sprints, Retrospektiven und agilen Werten Rating: 4 out of 5 stars4/5Agiles Coaching als Erfolgsfaktor: Grundlagen des Coachings, um Agile Teams erfolgreich zu managen Rating: 0 out of 5 stars0 ratingsProjektmanagement: - lernen, lehren und für die Praxis Rating: 0 out of 5 stars0 ratingsScrum: Agiles Projektmanagement und Scrum erfolgreich anwenden Rating: 0 out of 5 stars0 ratingsAgile Muster und Methoden: Agile Softwareentwicklung maßgeschneidert Rating: 0 out of 5 stars0 ratingsRetrospektiven - kurz & gut Rating: 0 out of 5 stars0 ratingsAgile Softwareentwicklung: Werte, Konzepte und Methoden Rating: 0 out of 5 stars0 ratingsKanban für Anfänger: Grundlegendes über den Einsatz von Kanban in der Industrie und der Softwareentwicklung Rating: 0 out of 5 stars0 ratingsAgiles Requirements Engineering und Testen Rating: 0 out of 5 stars0 ratingsScribble: Das Arbeitsbuch für agiles Prozessmanagement Rating: 0 out of 5 stars0 ratingsSoftwareentwicklungsprozess: Von der ersten Idee bis zur Installation Rating: 0 out of 5 stars0 ratings
Software Development & Engineering For You
KOMA-Script: Eine Sammlung von Klassen und Paketen für LaTeX 2e Rating: 0 out of 5 stars0 ratingsKanban für Anfänger: Grundlegendes über den Einsatz von Kanban in der Industrie und der Softwareentwicklung Rating: 0 out of 5 stars0 ratingsDesign Thinking für Anfänger: Innovation als Faktor für unternehmerischen Erfolg Rating: 0 out of 5 stars0 ratingsEinfach Java: Gleich richtig programmieren lernen Rating: 0 out of 5 stars0 ratingsDas große Python3 Workbook: Mit vielen Beispielen und Übungen - Programmieren leicht gemacht! Rating: 4 out of 5 stars4/5Projekt Unicorn: Der Roman. Über Entwickler, Digital Disruption und das Überleben im Datenzeitalter Rating: 0 out of 5 stars0 ratingsAgile Spiele – kurz & gut: Für Agile Coaches und Scrum Master Rating: 0 out of 5 stars0 ratingsLean Production - Grundlagen: Das Prinzip der schlanken Produktion verstehen und in der Praxis anwenden. Schlank zur Wertschöpfung! Rating: 0 out of 5 stars0 ratingsDigital Painting Workbook Rating: 0 out of 5 stars0 ratingsDigital Paintbook Volume 3 Rating: 5 out of 5 stars5/5Softwareentwicklungsprozess: Von der ersten Idee bis zur Installation Rating: 0 out of 5 stars0 ratingsProgrammieren lernen mit Python 3: Schnelleinstieg für Beginner Rating: 0 out of 5 stars0 ratings3D-Drucken für Einsteiger: Ohne Frust 3D-Drucker selbst nutzen Rating: 0 out of 5 stars0 ratingsLean Management für Einsteiger: Erfolgsfaktoren für Lean Management – Lean Leadership & Co. als langfristige Erfolgsgaranten Rating: 0 out of 5 stars0 ratingsSketchnotes in der IT: Abstrakte Themen mit Leichtigkeit visualisieren Rating: 0 out of 5 stars0 ratingsPrinzipien des Softwaredesigns: Entwurfsstrategien für komplexe Systeme Rating: 0 out of 5 stars0 ratingsAgiles Requirements Engineering und Testen Rating: 0 out of 5 stars0 ratingsKompaktes Managementwissen: Die Grunstruktur agiler Prozesse Rating: 0 out of 5 stars0 ratingsZertifizierung für Softwarearchitekten: Ihr Weg zur iSAQB-CPSA-F-Prüfung Rating: 0 out of 5 stars0 ratingsAgiles Coaching als Erfolgsfaktor: Grundlagen des Coachings, um Agile Teams erfolgreich zu managen Rating: 0 out of 5 stars0 ratingsSoftwaredesigndokumente - sinnvoller Einsatz im Projektalltag: Sinnvoller Einsatz im Projektalltag Rating: 0 out of 5 stars0 ratingsScrum: Agiles Projektmanagement und Scrum erfolgreich anwenden Rating: 0 out of 5 stars0 ratingsGrundlagen und Methoden der Wirtschaftsinformatik: Eine anwendungsorientierte Einführung Rating: 0 out of 5 stars0 ratingsSoftwarearchitektur für Dummies Rating: 0 out of 5 stars0 ratingsAutomatisiertes Testen: Testautomatisierung mit Geb und ScalaTest Rating: 0 out of 5 stars0 ratingsIT Wissensmanagement: Theorie und Praxis Rating: 0 out of 5 stars0 ratingsUML @ Classroom: Eine Einführung in die objektorientierte Modellierung Rating: 0 out of 5 stars0 ratingsBessere Softwareentwicklung mit DevOps Rating: 0 out of 5 stars0 ratings
Reviews for Scrum
19 ratings3 reviews
- Rating: 3 out of 5 stars3/5I agree with the reviews below. Save your money and just find good agile websites. Nothing revolutionary or even explanatory (real world examples) with this one. Good for beginners but definitely think twice before buying it. If you can borrow it, the better.
- Rating: 3 out of 5 stars3/5The book doesn't add much to the current literature.Most of it can be found in most other agile project management books. During all the time I was reading it, i was wondering whether the target audience was product managers/owners or scrum masters!What is not in other agile development books can be found in other product management books/blogs/articles or even in the Pragmatic Marketing framework.To summarize I fully agree with TadAd: There just isn't enough to justify purchasing this
- Rating: 2 out of 5 stars2/5The book is 118 pages long. When I think about the duplication in various sections of it, there's probably around half that many pages of content. I'd divide that content into two type of material. The first is the same introductory information that you'd get if you downloaded Schwaber and Sutherland's overview of Scrum from scrum.org. The second type of material consists of discussions about pitfalls in implementing Scrum, pitfalls in management practices, as well as a very brief look at things like burndown charts and different ways of slicing a development project.That first type of material is available for free; this book is $35...you do the math on that one. The second type of material isn't weighty enough to carry the price load—I really see it as a 25 page introductory chapter in a larger book that provides some real meat.There just isn't enough here to justify purchasing this. Put the money toward something that provides more depth.
Book preview
Scrum - Roman Pichler
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 Schwaber
Scrum Evangelist and Author
Boston, 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