Scrum Detailbetrachtung: Scrum Rollen

23. März 2011

Innerhalb des Scrum Prozesses werden folgende unterschiedliche Scrum Rollen definiert. Dies sind im engeren Sinne der Product Owner, das Team und der Scrum Master.

Zusätzlich dazu müssen noch folgende weitere Rollen, wie im üblichen klassischen Projektumfeld auch beachtet werden. Hier sind exemplarisch der Kunde, der Manager und der User genannt. Diese sind zwar nicht Teil des eigentlichen Scrum Prozesses, wirken aber auf diesen ein.

Die einzelnen Rollen im Detail

1. Der Product Owner

Der Product Owner sammelt die fachlichen Anforderungen an das zu realisierende Produkt. Er definiert die Produktfeatures, sowie die dazugehörigen Akzeptanzkriterien, und priorisiert diese abhängig vom Marktwert. Er kümmert sich um eine detaillierte Ausarbeitung der Anforderungen und bestimmt wann eine Aufgabe abgeschlossen ist.

Der Product Owner stellt die Schaltzentrale innerhalb des Scrum Prozesses dar. Er ist der Hauptansprechpartner sowohl für den Kunden, als auch für das Scrum Team, da er verantwortlich für das finanzielle Ergebnis des Projektes ist. (vgl. [Scrum kompakt], [Kriegerisch], [Maisch])

2. Das Team

Ein Team besteht typischerweise aus 5-9 Personen, die funktionsübergreifend einsetzbar sind (z.B. QS, Programmierer, UI-Designer, usw.). Das Team organisiert sich selber, in Bezug auf die Verantwortung für die Lieferung an den Product Owner (vgl. [Scrum kompakt], [Maisch]). Das Team besteht somit nur aus den Spezialisten. Hier zählen weder Product Owner noch Scrum Master dazu.

Das Team schätzt die Komplexität von Backlog-Einträgen, erstellt und aktualisiert das Sprint-Backlog, misst den eigenen Fortschritt, verspricht die Lieferung im Sprint und liefert am Ende des Sprint die versprochenen Features.

3. Der Scrum Master

Der Scrum Master schützt das Scrum Team vor äußeren Störungen und hilft bei der Prozess-Verbesserung / -Anpassung. Er unterstützt die enge Zusammenarbeit zwischen allen beteiligen Rollen und Funktionen innerhalb des Scrum Prozesses.

Der Scrum Master beseitigt Hindernisse und ist verantwortlich für die Einhaltung von Scrum-Werten und -Techniken. Zusätzlich dazu fördert er das Verständnis von Scrum in der Organisation, wie beispielsweise die Außenwahrnehmung und den Rückhalt (vgl. [Scrum kompakt], [Maisch]).

4. Der Kunde

Der Kunde finanziert die Produktentwicklung. Er gibt den Auftrag für die Umsetzung und kommuniziert mit dem Product Owner über den erwarteten Return on Investment. (vgl. [Gloger])

5. Der Manager

Der Manager oder das Management allgemein stellt die Umgebung der Produktentwicklung bereit und stellt die Qualität der Mitarbeiter durch Personalentwicklung und Trainings sicher (vgl. [Scrum kompakt]).

6. Der User

Die User stellen den Benutzer des Produktes dar. Für sie wird das Produkt entwickelt, und sie kennen eventuell schon Arbeitsabläufe / Workflows oder auch Probleme mit bereits vorhandenen Tools oder Produkten. Diese Workflows sollten als Input in das Product Backlog übernommen werden. Entweder als Beschreibung oder als Akzeptanzkriterien.

Das Feedback der User wird, sofern möglich, in jedem Review Meeting eingeholt, um den neuen Arbeitsablauf so effektiv wie möglich zu gestalten. (vgl. [Gloger2], [Maisch])

In der Praxis

In der Praxis ist eine reine Trennung der Rollen sehr selten vorzufinden. Oftmals werden in Projekten stark multitaskende Teams eingesetzt. Diese Vorgehensweise erweist sich jedoch nicht nur im Scrum-Kontext als besonders unproduktiv. Natürlich hat Multitasking Vorteile wie beispielweise die gleichzeitige Bearbeitung wichtiger Projekte. Leider existieren hier auch einige Nachteile, wie beispielsweise ein hoher persönlicher Stressfaktor, sowie das Problem, dass alle Punkte nur mit niedriger Qualität erledigt werden (vgl. [Vercillo]).

Das Ziel mittels Scrum ist somit ein Team ohne Multitasking als eingespieltes Team zur Aufgabenabarbeitung mit gleichmäßigem Arbeitsfluss während der gesamten Laufzeit einzusetzen. Nur so kann eine hohe Produktivität, sowie verlässliche vom Team zugesagte Lieferumfänge, mit einem geringen Verwaltungs-Overhead realisiert werden (vgl. [Roock]). Abweichungen im Projektverlauf werden nichtsdestotrotz mittels der Scrum-Kennzahlen (z.B. Burndown-Charts, Velocity) sofort ersichtlich, sodass frühzeitig reagiert und gegengesteuert werden kann.

In der Praxis wird häufig auch der klassische Projektmanager als Scrum Master in einem Projekt eingesetzt. Hierbei muss geprüft werden welche Funktionen der klassische Projektmanager im agilen Scrum-Projekt einnehmen soll: Die des Projektplaners (Product Owner) oder die des Coachs (Scrum Master). Es ist somit zu prüfen wie die Aufgaben des klassischen Projektmanagers im agilen Kontext definiert werden sollen, und welche Fähigkeiten der klassische Projektmanager mitbringt:
„Die “Reinkarnation” des Projektmanagers kommt dabei in vielschichtigen Formen. Der Scrum Master ist so eine Reinkarnation – er übernimmt klassische technische und soziale Teamaufgaben und hilft bei Koordination und Organisation. Der Product Owner kümmert sich um das “geschäftliche”, also Kunden, Anforderungen, Budgets und zeitliche Abläufe. Die übrigen Aufgaben des Projektmanagements werden auf das gesamte Team verteilt. Doch der Projektmanager als Person ist von der Bildfläche verschwunden.
[…]
Ist also ein Projektmanager stark in den Disziplinen Kundenkontakt, Analyse, Steuerung, Budgetierung und hat das “Führungs-Gen”, dann sollte er sich mit der Rolle des Product Owners anfreunden. Ist er jedoch stark bei technischer Kenntnis, sozialem Umgang, Hilfsbereitschaft, Metriken und Dokumentation (siehe Servant Leadership), ist für Ihn wohl eher der Scrum Master ein geeignetes Tätigkeitsfeld.“ (vgl. [Cetinkaya])

 

Literatur:

[Maisch] Die Scrum-Sprechstunde: Rollen in Scrum von Alexander Maisch [Juli 2008]

[Scrum kompakt] Einführung in Scrum > Rollen von Scrum Kompakt [2011]

[Kriegerisch] Scrum Rollen von Alexander Kriegerisch

[Gloger] Scrum Rollen | Der Kunde | Customer von Boris Gloger [August 2008]

[Gloger2] Scrum: Produkte zuverlässig und schnell entwickeln von Boris Gloger [Juli 2009]

[Vercillo] Pros and Cons of Multi-Tasking von Kathryn Vercillo [April 2009]

[Roock] Singletasking: Perspektivenwechsel – eine agile Kolumne von Arne Roock [April 2010]

[Cetinkaya] Die Zukunft des Projektmanagers in der Software-Entwicklung von Ilker Cetinkaya [November 2008]