Die 3 Scrum-Rollen: Verantwortung im Team verteilen

Scrum: eine kompakte Einführung

Scrum ist als agiles Framework in der Softwareentwicklung entstanden. Heutzutage wird es auch in vielen anderen Bereichen eingesetzt und eignet sich vor allem in der fortlaufenden Produktentwicklung und bei Projekten mit längerer Dauer. Im Gegensatz zum klassischen Projektmanagement arbeitet Scrum in kurzen Planungshorizonten und Arbeitszyklen, den sogenannten Sprints. Ein Sprint dauert in der Regel zwei bis drei Wochen, maximal jedoch einen Monat. Am Ende jedes Sprints liefert das Scrum-Team ein Produktbestandteil (Inkrement) aus, der bereits einen Nutzen für den Kunden bietet.

Komplexe Projekte oder Produkte können so mit Scrum in kleine Schritte aufgeteilt werden. Dieser „inkrementelle Ansatz“ bietet einige Vorteile:

• schnelles sichtbares Ergebnis für Kund*innen
• Team kann flexibel auf Veränderungen und neue Anforderungen im Projektzyklus reagieren
• Framework hilft dem Team, sich auf den Kundenmehrwert der geschaffenen Arbeitsergebnisse zu fokussieren
• Feedback von Kund*innen und anderen Stakeholdern kann während des Projektzyklus aufgenommen und verarbeitet werden

Die 4 Scrum-Meetings

Scrum ist ein Vorgehensmodell, das einen Rahmen zur Organisation der täglichen Zusammenarbeit setzt. Darin kann das Team Methoden einsetzen oder nutzen und Prozesse abbilden. Es entwickelt eine Lösung. Wie es seine Arbeit erledigt, entscheidet das Team eigenständig. Es führt sich selbst, ohne auf Führungskräfte im klassischen Sinn zurückzugreifen.

Das Scrum-Framework gibt dabei die grundlegende Struktur für Meetings, Artefakte und Zuständigkeiten vor. So ist ein Sprint üblicherweise in vier Meetings organisiert:

• Sprint Planning: In dem Planungstreffen legt das Team fest, welche Aufgaben und Arbeiten innerhalb des Sprints erledigt werden.
• Daily Standup: Im täglichen Meeting bespricht das Team die aktuellen Aufgaben des Tages. Auch Probleme oder Barrieren, die die Arbeit behindern, sind Thema im Daily.
• Sprint Review: In der Review präsentiert das Scrum-Team die Sprint-Ergebnisse und holt Feedback von Stakeholdern und Kund*innen ein.
• Sprint Retrospective: Die Retrospektive findet am Ende des Sprints statt und hilft dem Team, die interne Zusammenarbeit zu verbessern. Im Rückblick reflektiert das Team, was gut funktioniert hat, was weniger gut lief und was verbessert werden kann.

Scrum-Rollen und Verantwortlichkeiten im Team

Innerhalb des Scrum-Frameworks organisiert sich das Team selbst. Es verteilt die Zuständigkeiten und Verantwortung für die einzelnen Tätigkeiten auf die drei Scrum-Rollen Product Owner, Entwickler*innen und Scrum Master. Im Team existiert deshalb auch keine Hierarchie. Nach dem Scrum-Guide ist das Scrum-Team eine „geschlossene Einheit von Fachleuten“.

Die Scrum-Rollen stellen keine Positionsbezeichnungen dar: Je nach Produkt, Service oder Lösung, die entwickelt wird, ist das Team mit unterschiedlicher Expertise besetzt. Bei der Entwicklung einer Banking-App sind andere Kompetenzen gefragt als bei der Konzeption eines Online-Magazins. So kann das Entwickler-Team beispielsweise aus Backend- und Frontend-Developer*innen und UX-Designer*innen oder aus Grafiker*innen und Texter*innen bestehen. Oder aus allen vier dieser Kompetenzen.

Product Owner: Hüter des Backlogs mit Produktvision

Der Product Owner (PO) hat die Produktvision im Blick: Er gibt die Zielrichtung vor und ist ergebnisverantwortlich für die „Maximierung des Wertes des Produkts“ (Scrum-Guide). Als Interessensvertreter der Kund*innen und anderer Stakeholder des Unternehmens sammelt er die Anforderungen an das Produkt im Product Backlog und verwandelt sie in zu bearbeitende Aufgaben (Backlog-Items). Diese Backlog-Items sind so konzipiert, dass sie innerhalb eines Sprints abgeschlossen werden können.

Der Product Owner priorisiert die Aufgaben und legt fest, in welcher Reihenfolge die Backlog-Einträge bearbeitet werden. Für eine erfolgreiche Zusammenarbeit muss das Team den Entscheidungen zustimmen bzw. diese akzeptieren. In der Praxis nimmt der PO die Priorisierung in der Regel auch gemeinsam oder in Rücksprache mit dem Team vor. Er sorgt dafür, dass der Product Backlog transparent und für alle einsehbar ist. Wer die Einträge im Backlog oder die Reihenfolge ihrer Bearbeitung ändern möchte, muss den PO von dieser Notwendigkeit überzeugen. Die letzte Entscheidung liegt aber immer beim Product Owner. Er ist auch der Einzige, der die Autorität hat, einen Sprint vorzeitig abzubrechen.

Zusammenfassend trägt der Product Owner die Verantwortung für drei Aufgaben:

• Management des Product Backlogs: Der PO formuliert das Produktziel und erstellt die Backlog-Einträge. Zudem priorisiert er die Reihenfolge der Einträge und stellt sicher, dass das Backlog transparent, sicher und verständlich ist. Er kann Teile dieser Aufgaben (z. B. Erstellung der Backlog-Einträge) an das Team delegieren. Dennoch bleibt er ergebnisverantwortlich für den Mehrwert des zu entwickelnden Produkts.
• Stakeholder-Management: Der Product Owner bezieht die Interessen aller Stakeholder des Produkts (Nutzer*innen, Kund*innen, Unternehmensvertreter*innen) ein. Er muss dementsprechend im regelmäßigen Austausch mit diesen Gruppen sein und ihre Anforderungen aufnehmen. Nur so kann er sicherstellen, dass die Backlog-Einträge sinnvoll strukturiert sind und die Entwickler*innen einen Mehrwert schaffen können.
• Release-Management: Der PO muss immer im Blick haben, wann die die entwickelten Lösungen zum Nutzer kommen. Es gibt im Sprintzyklus keine festen Releasedaten. Das Team kann jederzeit ausliefern, ideal sind mehrere Releases während des Sprints. Aus diesem Grund muss der Product Owner immer wissen, wann die einzelnen Inkremente veröffentlicht werden können.

Entwickler*innen: Team aus Machern schafft Mehrwert

Die Entwickler*innen sind die operativen Fachexpert*innen im Team. Sie sind es, die das Produkt erstellen bzw. in jedem Sprint ein Produkt-Inkrement liefern. Das bedeutet aber nicht, dass alle Entwickler*innen „gleich“ sind oder die gleichen Aufgaben haben. Im Gegenteil: In der Regel ist dieses „Macher-Team“ eine crossfunktionale Gruppe von Fachkräften mit unterschiedlichen Kompetenzen, die gemeinsam an der Erstellung des Produkts arbeiten. Sie organisieren sich eigenständig und entscheiden, welche Arbeiten sie ausführen müssen, um das jeweilige Sprintziel zu erreichen.

Deswegen ist der Begriff „Entwickler*innen“ eventuell auch irreführend. Scrum stammt aus der Softwareentwicklung. In der ursprünglichen Anwendung bestand dieser Teil des Scrum-Teams in der Regel tatsächlich aus Software-Entwickler*innen. Da das Framework aber mittlerweile auch in anderen Bereichen eingesetzt wird, können die „Entwickler*innen“ auch Business-Analyst*innen, Marketing-Manager*innen oder HR-Business Partner*innen sein – eben die Personen, die eine Lösung für eine Nutzergruppe (unternehmensintern oder extern) erarbeiten. Der Einfachheit halber haben wir hier analog zum Scrum Guide den Begriff Entwickler*innen gewählt – auch wenn damit viele unterschiedliche Kompetenzen unter einer Bezeichnung zusammengefasst werden.

Zentrale Aufgabe des Entwicklungs-Teams ist es, in jedem Sprint einen Wert für die Kund*innen in Form eines Inkrements zu liefern. Dabei sind sie verantwortlich dafür,

• einen Plan für den jeweiligen Sprint zu erstellen,
• die Qualität zu sichern durch das Einhalten einer gemeinsam definierten Definition of Done und der Erfüllung der Requirements, die in den einzelnen Backlog-Items definiert wurden,
• täglich den Plan zur Erreichung des Sprint‐Ziels anzupassen und
• sich gegenseitig als Expert*innen zu beraten.

Scrum Master: Scrumexperte und Teamcoach

Der Scrum Master ist wie der Product Owner Servant Leader des Scrum-Teams. Das bedeutet aber nicht, dass er oder sie im Team eine herausgehobene Führungsrolle einnimmt. Er ist kein Projektleiter, der Aufgaben vorgibt und die Arbeit des Teams plant, sondern vielmehr ein Coach: Als methodischer Experte ist der Scrum Master verantwortlich dafür, dass die Scrum-Regeln und -Prinzipien im Team eingehalten werden. Er vermittelt die fünf Scrum-Werte (Mut, Fokus, Enagement, Respekt und Offenheit) und unterstützt seine Kolleg*innen darin, das Scrum-Framework effektiv umzusetzen.

Der Scrum Master schafft die bestmöglichen Rahmenbedingungen, damit das Team kundenzentriert und selbstorganisiert arbeiten kann. Er sorgt für einen störungsfreien Sprint und unterstützt die Entwickler*innen dabei, Hindernisse (Impediments) in der täglichen Arbeit zu beseitigen. Als Teammitglied verantwortet der Scrum Master die Zusammenarbeit und unterstützt Entwickler*innen und Product Owner bei der gemeinsamen Zielerreichung. Als Moderator stellt er zudem sicher, dass die vier Scrum-Events (Sprint Planning, Daily Standup, Sprint Review, Sprint Retrospective) stattfinden und produktiv sind.

Der Scrum-Guide unterstreicht die „dienende Funktion“ des Scrum Masters: So unterstützt er

• den Product Owner bei der Definition des Produkt-Ziels, beim Management des Product Backlogs und der Zusammenarbeit mit den Stakeholdern,
• die Entwickler*innen in der Selbstorganisation und bei der Fokussierung auf die Schaffung hochwertiger Inkremente sowie
• das Unternehmen bei der Einführung von Scrum.

Bonus-Rolle: Stakeholder

Unter den Stakeholdern versteht man alle Personen, die nicht zum Scrum-Team gehören, aber dennoch Interesse am Erfolg des Produkts haben oder notwendiges Wissen mitbringen. Das können Kund*innen, Auftraggeber*innen oder andere Unternehmensvertreter*innen sein. Stakeholder geben Anforderungen an das Produkt oder Projekt vor, an der operativen Umsetzung beteiligen sie sich nicht. Sie gehören also nicht zu den klassischen Scrum-Rollen.

Dennoch nehmen sie am Scrum-Prozess teil. So stehen sie im Austausch mit dem Product Owner und/oder den Entwickler*innen, um Anforderungen an das Produkt einzureichen oder zu ändern. Darüber lädt das Scrum-Team die Stakeholder zur Sprint Review ein und präsentiert ihnen die Ergebnisse des zurückgelegten Sprint-Zyklus. Hier können sie dann Feedback und Verbesserungsvorschläge geben.

Praxis-Beispiel: die Scrum-Rollen außerhalb der Softwareentwicklung

Viele Scrum-Beispiele stammen aus der Softwareentwicklung. Wie schon oben geschrieben, lässt sich das Framework aber auch gut in anderen Bereichen umsetzen. Im Folgenden skizzieren wir die Scrum-Rollen an einem (fiktiven) Beispiel, das nicht aus der Softwareentwicklung stammt: Die Redaktion einer monatlich erscheinenden Zeitschrift hat beschlossen, ihr Magazin künftig mit Scrum zu entwickeln. Die frühere Redaktionsleiterin Claudia ist nun Product Owner. Sie pflegt und verwaltet den Redaktionsplan in Form eines Backlogs und priorisiert die Themen, die pro Ausgabe abgedruckt werden. Das Entwicklungsteam besteht u. a. aus Redakteur*innen, Grafiker*innen und Anzeigenverkäufer*innen, die die Zeitschrift mit Inhalten füllen. Ein neu eingestellter Scrum Master unterstützt das Team in den Regel-Meetings und sorgt dafür, dass das Team ungestört an seinen Themen arbeiten kann.

Ihr Produkt ist die final entwickelte Zeitschrift – vor Drucklegung und Versand. Diese Aufgaben werden in anderen Teams erledigt. In jedem Sprint entwickelt das Team eine Ausgabe des Magazins. Im Sprint Planning zu Beginn des Produktionszyklus treffen sich alle Teammitglieder, um die Ausgabe zu planen: Ein Titelthema wird ausgewählt und die Redakteur*innen ziehen sich die Artikel, an denen sie arbeiten werden. Innerhalb des Sprints gestalten sie zudem mit den Grafiker*innen das Layout der Seiten, suchen Bilder aus und setzen Infografiken ein. Die Anzeigenverkäufer*innen nehmen die Themen der Ausgabe als Aufhänger, um Anzeigenkund*innen zu akquirieren.

Der Sprintzyklus in der Zeitschriftenproduktion

Im täglichen 15-minütigen Redaktionsmeeting (Daily Standup) hält sich das Team auf dem Laufenden: Wo hakt es gerade? Wer benötigt weitere Informationen? Wer kennt eventuell einen kompetenten Interviewpartner für ein Thema der Ausgabe? Parallel zur Produktion prasselt eine Beschwerde ein: Ein Unternehmen fühlt sich in der letzten Ausgabe falsch dargestellt und verlangt eine Gegendarstellung. PO Claudia spricht dies im Daily an und möchte das Thema mit in die Ausgabe nehmen. Scrum Master Michael hält dagegen und möchte den Sprint schützen. Im Gespräch mit Claudia suchen sie gemeinsam nach einer Lösung: Ist die Gegendarstellung so wichtig, dass sie ins Heft aufgenommen und der Backlog während des laufenden Sprints neu sortiert wird? Und welches geplante Thema wird dafür aufgegeben? Oder kann die Gegendarstellung in die nächste Ausgabe übernommen werden? Sie beschließen, die Gegendarstellung zu verschieben. PO Claudia tritt mit dem beschwerenden Unternehmen in Verbindung und erläutert die Entscheidung.

Sales Manager Mesut schlägt Alarm: Kunde Firma Müller hat seine bis Ende des Jahres gebuchten Anzeigenplätze storniert und der Verkauf für die aktuelle Ausgabe verläuft stockend. Scrum Master Michael schließt sich mit Mesut und den drei Sales-Kolleg*innen in einem eintägigen Workshop zusammen, um alternative Finanzierungsmöglichkeiten zu erörtern.

Team nimmt Feedback in Sprint-Review auf 

Redaktionsschluss: Es ist vollbracht. Die Ausgabe ist fertig und kann in Druck gehen. Parallel zur Veröffentlichung veranstaltet das Team im Rahmen ihrer Sprint Review eine öffentliche Blattkritik, an der auch Leser*innen und andere Stakeholder aus dem Verlag (z. B. Geschäftsführung und Vertriebsteam) teilnehmen. Das Team präsentiert die aktuelle Ausgabe und nimmt Feedback und Verbesserungsvorschläge auf: Vertriebsmitarbeiterin Cordula hätte in der Zukunft gerne eine reißerischere Titelseite, um den Absatz am Kiosk zu steigern. Leser Fritz wünscht sich eine tiefere Analyse von Thema Y und abwechslungsreichere Darstellungsformate im Magazin.

Am Ende des aktuellen Sprints und vor Beginn der nächsten Ausgabe trifft sich das Team zu einer Sprint Retrospective. Während in der Review die Ergebnisse des letzten Sprints (die aktuelle Ausgabe) im Fokus stand, bezieht sich die Retrospektive auf die Zusammenarbeit. Scrum Master Michael führt durch das Meeting und notiert die Ideen und Verbesserungsvorschläge, die hier gesammelt werden: Was haben wir bei der Produktion der aktuellen Ausgabe gelernt? Was können wir beim nächsten Mal besser machen? Und wie können wir das Feedback aus der Sprint Review aufnehmen? Die Retrospektive schließt den aktuellen Sprintzyklus ab. Das Magazin liegt am Kiosk und in den Briefkästen der Abonnent*innen. Nun kann der nächste Sprint beginnen.

Fazit: die verteilte Verantwortung der Scrum-Rollen 

Scrum eignet sich vor allem in der fortlaufenden Produktentwicklung und bei Projekten mit längerer Dauer. Entstanden in der Softwareentwicklung verwenden heutzutage Teams aus vielen unterschiedlichen Bereichen das agile Framework. Scrum arbeitet in kurzen Planungszyklen: In den Sprints können komplexe Projekte oder Produkte in einem inkrementellen Ansatz entwickelt werden.

Das Scrum-Team besteht aus den Scrum-Rollen Product Owner, Scrum-Master und Entwickler*innen. Alle Mitglieder agieren auf Augenhöhe und verteilen die Verantwortung für die Aufgaben auf die drei Teamrollen. Das Scrum-Team ist eine „geschlossene Einheit von Fachleuten“, das an einem gemeinsamen Ziel arbeitet.