2 Die Rollen in Scrum

Der Begriff „Scrum“ kommt aus dem Rugby-Sport, er kann mit „Gedränge“ übersetzt werden. Gemeint ist jedoch die beim Scrum im Rugby übliche Bewegung des gesamten Teams als Einheit, um den Ball auf der eigenen Seite hinauszudrängen. Wie bereits erwähnt, stützen sich agile Vorgehensweisen auf kleine, selbstorganisierte Teams. In Scrum übernimmt das gesamte Team die Verantwortung für ein Etappenziel – sinngemäß ist ein Sprint eine Bewegung des gesamten Teams über eine Etappe.

Scrum definiert drei wesentliche Rollen, deren Aufgaben und Verantwortungen genau aufgeteilt und definiert sind: Product Owner, Umsetzungsteam (meist nur als Team bezeichnet) und Scrum Master. Alle drei zusammen werden Scrum Team genannt.

Abbildung 2.1: Das Scrum Team

Die kollektive Verantwortung des Scrum Teams ist es, ein Produkt an Kunden oder Interessensvertreter (Stakeholder), wie Manager, Fachbereiche etc. zu liefern. Obwohl diese anderen beteiligten Personen auch wichtig sind, werden sie in Scrum nicht mit einer Rolle und damit mit einer innerhalb von Scrum definierten Verantwortung belegt.

Die drei Scrum-Rollen sollen idealerweise in hundertprozentiger Wahrnehmung und nicht über Rollenteilung besetzt werden. Der Product Owner vertritt in Scrum die Geschäftsseite (mit Krawatte dargestellt) und der Scrum Master (mit Kappe gezeichnet) kann als Teamcoach verstanden werden.

2.1 Der Product Owner

Der Product Owner (P.O.) verantwortet den geschäftlichen Erfolg des zu entwickelnden Produkts, ist also für die Rentabilität (= ROI, Return on Invest) des Entwicklungsvorhabens (Produkt oder Projekt) verantwortlich. Er oder sie stellt sicher, dass das richtige Produkt entwickelt wird und definiert dazu die Produkteigenschaften, verfeinert sie zu konkreten Anforderungen, löst Fragen zu Anforderungen und stellt sicher, dass die richtigen Funktionalitäten zum richtigen Zeitpunkt (Prioritäten) geliefert werden.

Hauptverantwortung: Rentabilität des gelieferten Produkts

Der Product Owner arbeitet mit den Kunden, Anwendern und Stakeholdern zusammen. Er konsolidiert die Wünsche der verschiedenen Beteiligten und bestimmt letztendlich Umfang und Reihenfolge der gelieferten Funktionalitäten, um mit dem Produkt stets den besten Geschäftswert zu liefern. Die Anforderungen werden abhängig von ihrem Wert (also potenzieller Umsatz oder Kostenersparnis durch Software) und den damit verbundenen technischen Risiken in Form einer Liste, dem Produkt-Backlog, gereiht.

Aufgrund dieser Verantwortung ist der Product Owner in Scrum auch der einzige, der die Reihenfolge der gewünschten Lieferungen – also die Sortierung des Produkt-Backlogs – bestimmt, auch wenn viele Faktoren und Personen darauf Einfluss nehmen.

Eine Vision etablieren

Der Product Owner ist auch dafür verantwortlich, eine Produktvision zu etablieren, die kommuniziert werden kann. Dabei geht es darum, ein grobes Ziel aufzuzeigen: was das Produkt werden soll und warum es entwickelt wird. Diese Vision dient dem Scrum Team als Leitlinie durch das Entwicklungsvorhaben. Mit der Vision und dem Produkt-Backlog wird der fachliche („Was?“) und nichtfunktionale („Wie gut?“) Teil der Anforderungen definiert.

Ein wesentlicher Unterschied zur klassischen Arbeitsweise ist die in Scrum bevorzugte persönliche Kommunikationsschnittstelle zwischen Anforderer und Umsetzer. Verschriftlichte Anforderungen (Dokumente, Wikiseiten etc.) sind zwar erlaubt, Scrum fordert aber die direkte (Face-to-Face-) Kommunikation zwischen Team, Product Owner oder Kunde. In der Regel handelt es sich bei Scrum um eine artefaktreduzierte Entwicklung, also mit weniger Dokumenten und mehr Kommunikation. Der Umfang an Dokumentation, insbesondere anforderungsseitig, liegt im Ermessen des Product Owners bzw. ist an die organisatorischen Rahmenbedingungen gebunden (Governance).

Resultate akzeptieren oder ablehnen

Als Produktverantwortlicher hat der Product Owner auch die Aufgabe, die vom Umsetzungsteam gelieferten Ergebnisse zu inspizieren und sie entweder zu akzeptieren oder zurückzuweisen. Das tut er oder sie, indem zu gelieferten Ergebnissen Feedback gegeben wird – damit ist das Umsetzungsteam in der Lage, sich regelmäßig über die Anforderungen und deren kollektivem Verständnis informieren zu können. Formal gesehen ist der Product Owner für die Abnahme der Lieferungen verantwortlich, in der Praxis wird er oder sie das nicht alleine tun, sondern auch die anderen Beteiligten1 einbeziehen. Die Wichtigkeit dieser Feedbackschleife darf nicht unterschätzt werden. Nur damit wird es möglich, dass die Mitglieder des Teams über die Zeit zu umfassendem Domänenwissen gelangen und verstehen lernen, wie die Produkte, die sie entwickeln, von den Anwendern verwendet werden.

Agiles Anforderungsmanagement – Backlog-Pflege

Die laufende Pflege des Produkt-Backlogs wird in Scrum Backlog Grooming genannt und ist eine weitere Verantwortung des Product Owners, die sich aus seiner Hauptverantwortung ableitet. Das Produkt-Backlog ist eine Liste, die sich laufend verändert – es werden Einträge hinzukommen, manche werden entfallen, die Reihenfolge wird sich ändern – gemäß den agilen Grundsätzen wollen wir auch auf Veränderungen im Umfeld reagieren können, um gesteigerten Wert auf Basis neuer Erkenntnisse zu liefern. Da wir nicht alle Details zu Anforderungen im Voraus analysieren, müssen Anforderungen im Zuge ihres Laufs durch das Backlog ständig detailliert und verfeinert werden. In weiterer Folge hat der Product Owner ein vitales Interesse an Aufwandsabschätzungen der einzelnen Einträge im Backlog, um planen zu können.

In der Praxis eines Scrum Teams befindet sich das Produkt-Backlog ständig in Bewegung und verlangt somit nach ständiger Arbeit.

Management von Lieferungen (Releases)

Neben dem aktiven Management von Anforderungen gehört es zu den Aufgaben des Product Owners, die Lieferungen zu planen. Er bestimmt über diese (laufende) Planung, zu welchem Zeitpunkt welche Funktionalitäten geliefert werden. Über die Sequenz von mehreren Sprints hinweg entsteht zunehmend mehr Funktionalität, die an den Kunden geliefert werden kann. Deren Umfang sowie den Zeitpunkt der tatsächlichen Auslieferung bestimmt der Product Owner auf der Basis marktwirtschaftlicher Fakten. Auch wenn Scrum ein „auslieferbares Produktinkrement“ am Ende eines jeden Sprints fordert, muss ein einzelnes Sprint-Ergebnis nicht unbedingt auch jedes Mal an den Kunden2 ausgeliefert werden.

Neben der Planung dieser „Releases“ verantwortet der Product Owner das Management der Erwartungshaltungen der Beteiligten. Immerhin verspricht er (sich) ja eine gewisse Rentabilität und reiht die Umsetzung bestimmter Anforderungen. Unrealistische oder nicht der Reihenfolge entsprechende Wünsche von Beteiligten können und sollen bereits früh im Entwicklungsprozess artikuliert werden.

Kein Projektleiter

Die Rolle des Projektleiters gibt es in Scrum nicht. Auch wenn der Product Owner viele Aufgaben und Verantwortungen übernimmt, gehören viele klassische Projektmanagementaufgaben nicht zu seiner Agenda, sondern liegen auch beim Team und dem Scrum Master.

Der Product Owner verfügt über umfassendes Domänenwissen und sowohl fachliche als auch Entscheidungskompetenz im Rahmen des Entwicklungsvorhabens. Er oder sie muss die Konsequenzen der von ihm oder ihr getroffenen Entscheidungen verstehen und tragen können.

Es ist zwar nicht erwünscht, aber auch nicht ungewöhnlich, dass ein Linienvorgesetzter der Teammitglieder die Rolle des Product Owners übernimmt. In solch einem Fall ist es aber nötig, dass er die Selbstorganisation des Teams respektiert und seine persönlichen oder Bereichsziele nicht im Widerspruch zu den Zielen des Scrum Teams stehen.

2.2 Das Umsetzungsteam

Während in der Rolle des Product Owners eher die fachliche Seite vertreten wird, steht das Umsetzungsteam, meist nur „Team“ genannt, eher für die Seite der technischen Realisierung oder den „Wie“-Teil.

Hauptverantwortung: Anforderungen in Software umsetzen

Mit „eher“ soll deutlich gemacht werden, dass auch das Team in der Verantwortung steht, über die Anwendungsdomäne zu lernen und bei der Arbeit am Produkt-Backlog mitzuhelfen. Zur Hauptverantwortung und damit einhergehenden Kernkompetenz des Teams zählt jedoch die Umsetzung der gewählten Anforderungen in qualitativ hochwertige, lauffähige Software.

Scrum fordert diese Umsetzung innerhalb eines fest definierten, tendenziell eher kurzen Zeitraums, eines Sprints – der typischen Länge von zwei oder drei Wochen. Dabei kann selbstverständlich kein ganzes Produkt entstehen. Wir sprechen daher von einem Inkrement, einem kleinen, vertikalen Durchstich mit brauchbarer Funktionalität. Während es die Aufgabe des Product Owners ist, die Werthaltigkeit dieser Lieferung zu verantworten, hat das Team die Verantwortung, sie in hoher Qualität umzusetzen.

Dazu plant es den Sprint und entscheidet in der Sprint-Planung, wie viele der am höchsten priorisierten Anforderungen im Sprint in einem auslieferbaren Zustand, also gänzlich fertig, getestet und fehlerfrei etc. umgesetzt werden können. Dazu zählt auch das Ausliefern selbst, also die Bereitstellung der Software auf einem System, das den realen Bedingungen ähnelt (produktionsnahe Umgebung, installierbare Desktopsoftware etc.). Das Team verantwortet damit den gesamten Zyklus von...