Im Rahmen des agilen Projektmanagements ist Scrum nicht mehr wegzudenken – und wird oft fälschlicherweise als Projektmanagement-Methode eingeordnet. Tatsächlich ist es aber ein Produktentwicklungs-Framework, d. h. ein Vorgehensmodell zum Bearbeiten komplexer Projektaufgaben. Auch Begrifflichkeiten wie Scrum Master, Artefakt oder Sprint werden oftmals unpräzise verwendet, was für Verwirrung sorgt. Wir arbeiten im Projektalltag regelmäßig mit Scrum und möchten unsere Leser*innen gerne an unseren Erfahrungen und Erkenntnissen teilhaben lassen.

In diesem Blogbeitrag stellen wir die Rollen in Scrum vor. Man teilt sie ein in

• Product Owner  
• Scrum Master 
• Development Team 

Was es genau damit auf sich hat, erläutern wir hier aus der Perspektive der einzelnen Rollen:

Als Product Owner... 

… bin ich für den Wert und die Wertmaximierung des Produktes zuständig. Ich vertrete die Anforderungen an ein Produkt und priorisiere seine Funktionalitäten, stelle mir die Frage, welchen Wert sie für die User haben. Ganz essenziell dafür ist die Produkt-Vision, also das Fernziel. Dies soll in den Köpfen des gesamten Teams verankert sein, um es in seinen Entscheidungen zu leiten. Um eine Produkt-Vision zu erstellen, gibt es in Scrum Best Practices, die einen unterstützen können – zum Beispiel „Die sechs Denkhüte“ oder die „Walt-Disney-Methode“.  

Das so genannte Artefakt, mit dem ich arbeite, ist der Product Backlog. Dieser umfasst die Funktionalitäten des Produktes und kann sich verändern und erweitern. Ich muss sicherstellen, dass er sichtbar, transparent und verständlich ist und dass für jeden klar ist, woran als nächstes gearbeitet werden soll. Zu meinen Aufgaben zählen auch Kommunikation und Austausch mit den Stakeholdern, also den internen und externen Anspruchsgruppen. Sie haben ein berechtigtes Interesse am Produkt und können zum Beispiel Wünsche äußern. An sie kommuniziere ich auch den Fortschritt des Produktes.  

Als Scrum Master... 

… erleichtere ich meinem Team das effektive Arbeiten. Hierzu schaffe ich eine Arbeitsumgebung, in der meine Kolleg*innen wachsen und sich weiterentwickeln können – eine wichtige Voraussetzungen für die Selbstorganisation im Team. Meinen Kolleginnen und Kollegen stehe ich als Coach, Teacher und Mentor zur Seite, der neu Erlerntes in die Tat umsetzt, den Scrum-Prozess vorantreibt und innerhalb des Unternehmens für den Wissenstransfer sorgt. Im Arbeitsalltag bedeutet dies, dass Scrum-Events (z. B. Dailys, Reviews, Retrospektiven etc.) wie geplant stattfinden und nachbereitet werden. Die Retrospektive ist mein „Haupt-Event“, bei dem ich dem ganzen Team die Bühne zur Reflexion bereite und somit den Lern-Effekt verstärke. Alltäglich gibt es auch Situationen, in denen ich den Teammitgliedern einfach den Rücken freihalte, damit sie möglichst ungestört durch äußere Faktoren arbeiten können (z. B. Ressourcen-Engpässe, Konflikte im Team, viele Termine außerhalb des Scrum-Projekts, etc.).

Letztlich wirke ich als „Change-Agent“ auch im Team- und Projektumfeld, d. h. innerhalb der gesamten Organisation, um die Arbeitsweise nach Scrum zu ermöglichen und ein Umdenken anzustoßen. Wenn ich all diese Aufgaben gut erledige, schaffe ich meine Rolle schlussendlich selbst ab – denn dann ist das Team in der Lage, selbstorganisiert zu arbeiten. 

Als Development Team... 

… sind wir interdisziplinär aufgestellt, tragen selbst die Verantwortung für das, was wir tun, und sind als Ganzes verantwortlich. Jeder im Team ist gleichberechtigter Developer, bei uns gibt es keine Unterschiede zwischen den Personen – egal, ob jemand Auszubildender oder Senior ist. Das gilt auch für die Verantwortung und Rechtfertigung unserer Arbeit gegenüber dem Product Owner und den Stakeholdern. 

Wir arbeiten hauptsächlich mit dem Sprint Backlog. Dieser besteht aus den Teilen des Product Backlogs, die wir im nächsten Sprint bearbeiten werden. Die Menge an Aufgaben stimmen wir mit dem Product Owner ab, aber am Ende liegt die Entscheidung bei uns. Wie wir unsere Aufgaben erledigen, entscheiden wir ebenfalls selbst.  

Im Optimalfall haben wir eine Teamgröße von drei bis neun Personen. Erfahrungsgemäß ist das klein genug, um schnell reagieren zu können, und groß genug, um einen angemessenen Fortschritt im Sprint zu erzielen.  

Was bedeutet das für das Rollenverständnis im Unternehmen? 

Gemeinsam bilden diese drei Rollen und die Personen, die sie in einem Projekt ausfüllen, das Scrum-Team. Einen klassischen Projektmanager gibt es nicht. Wir sprechen hier ganz selbstverständlich von einer Rollendefinition, die sich meist erst einmal nicht mit den in Unternehmen oder Team vorherrschenden individuellen Stellenbeschreibungen deckt. 

Scrum arbeitet im Grunde mit einem strukturell-hierarchisch sehr einfachen (flache Hierarchien), wenn auch radikalen Ansatz. Dieser zielt auf Selbstorganisation und Gleichberechtigung im Sinne einer gleich verteilten Verantwortung aller Mitglieder des Scrum-Teams ab. Voraussetzung dafür ist das Commitment des ganzen Teams und die Bereitschaft, sich auf neue Team-Strukturen einzulassen.  

Dies war unser Einstieg in eine Serie zum Thema Scrum, das uns und unsere Kunden fortwährend beschäftigt. Der nächste Beitrag folgt in Kürze.  

Quelle: Scrum Guide