Das Scrum-Rollenmodell: Drei Rollen, eine Verantwortung

Scrum ist einer der agilen Managementrahmenwerke, die sich sehr gut für die Projektarbeit eignen. Gerade und insbesondere dann, wenn komplexe Fragen- und Themenstellungen entwickelt werden müsen, ist Scrum ein gute Wahl.

Der Scrum-Leitfaden (die Ausführungen beziehen sich auf die deutschsprachige Fassung vom November 2017) sieht drei Rollen vor. Folgende Rollen werden definiert:

1. Product Owner
2. Entwicklungsteam
3. Scrum Master

Die Rolle des Product Owners hat ihren Fokus auf das „Mehrwert“ und das „Was“, das im Rahmen des Scrum-Projektes geschaffen werden soll. Die Rolle repräsentiert die Bedürfnisse und Wünsche der Auftraggeber im Projekt und achtet darauf, dass diese auch gewürdigt und berücksichtigt werden. Hinzu kommt das Entwicklungsteam, wir sprechen im Forum Agile Verwaltung gerne auch vom Umsetzungsteam. Hierbei handelt es sich um die Fachleute, die die Lösung „entwickeln“ und umsetzen. Dieses Umsetzungsteam besteht aus den Experten unterschiedlichster Fachrichtungen, die erforderlich sind, um gute Ergebnisse zu erzielen (Crossfunktionalität). Das Team der Experten organisiert sich selbst, weil sie als Fachleute am besten wissen, was sie benötigen, um ein gesetztes Ziel zu erfüllen. Idealerweise sind alle Mitglieder des Umsetzungsteams in der Lage, sich gegenseitig in ihren Aufgaben zu unterstützen, weshalb es innerhalb des Umsetzungsteams keine weitere Rollenunterteilung mehr gibt. Die Fachexperten haben ihren Fokus auf der Umsetzung und der Qualität der Umsetzung und arbeiten Hand in Hand mit dem Product Owner zusammen. Damit das Ganze funktioniert und zum Fliegen kommen kann, gibt es die Rolle des Scrum Masters als „Unterstützung“, die ihren Fokus auf der Produktivität des Scrum-Teams hat. Die wohl einzige Rolle innerhalb eines Scrum Teams, die darauf ausgelegt ist, sich in ferner Zukunft überflüssig zu machen.

Aus unserer Sicht ist wichtig zu verstehen, dass es innerhalb eines Scrum-Teams keine „echte“ Hierarchie gibt. Jede der drei Rollen ist gleichberechtigt, auch wenn jede der Rollen einen speziellen Fokus aufweist. Die Verantwortungsbereiche der verschiedenen Rollen überlappen sich bewusst. Das „zwingt“ die Mitglieder eines Scrum-Teams zur Zusammenarbeit und zum ständigen Dialog und soll sicherstellen, dass am Ende das Scrum-Team sich als ein Team versteht, das eine gemeinsame Verantwortung für das Ergebnis trägt. Es lässt sich sehr schön mit der Formel zusammenfassen: Drei Rollen, eine Verantwortung.

Zentral für das Verständnis von Scrum ist daher: Jede dieser drei Rollen hat einen Fokus im Sinne von „Führung“, und zugleich sind alle drei Rollen gleichermaßen für das Endergebnis verantwortlich. Ein deutlicher Bruch mit der tradierten Vorstellung, nach der eine Führungskraft die Verantwortung trägt. Zum besseren Verständnis werden wir uns die drei Rollen näher anschauen.

PRODUCT OWNER

Die Rolle des Product Owners wird vom Scrum-Leitfaden wie folgt beschrieben:

Die Rolle hat den Fokus klar und eindeutig auf dem „WAS“. Der Fokus der Rolle ist darauf ausgerichtet, die Interessen des Auftraggebers zu wahren. Der Product Owner ist die Schnittstelle zum Management und zu Kunden. Die Rolle kümmert sich darum, dass die Aktivitäten des Teams dazu beitragen, dass für den Auftraggeber Mehrwert geschaffen und erzeugt wird. Der Product Owner gibt den „Kurs“ innerhalb des Projekts vor und hilft damit. Der Product Owner ist der Navigator der Scrum-Teams. Die Rolle kümmert sich darum, dass regelmäßig der „Kurs“ bestimmt wird und die Basis dafür geschaffen wird, dass das Umsetzungsteam weiß, wohin es das „Schiff“ steuern soll.

In dieser Funktion ist der Product Owner in regelmäßigem Austausch mit dem Auftraggeber und den Anwendern der Ergebnisse des Teams, um deren Anforderungen als Wünsche und Bedürfnisse an den „Neuentwicklung“ zu antizipieren. In der Rolle des Product Owners wird die Auftragsverwaltung und das Feedbackmanagement kanalisiert und zusammengeführt. Anforderungen werden von der Person mit der Rolle des Product Owners aufgenommen und zusammengetragen, in enger Abstimmung mit dem Umsetzungsteam verfeinert und priorisiert.

Der Product Owner agiert, das ist wichtig, immer in enger Zusammenarbeit mit den weiteren Teammitgliedern. Idealerweise werden diese regelmäßig auch bei der Pflege des Backlogs eingebunden und beteiligt, da diese das fachliche Expertenwissen besitzen, das hierfür notwendig ist. Die Verantwortlichkeit des Product Owners bezieht sich darauf, dass der Backlog regelmäßig gepflegt wird und der Kontakt zu Auftraggeber und Usern regelmäßig und zielführend stattfindet. Dies bedeutet nicht zwangsläufig, dass der Product Owner im Alleingang agiert.

In diesem Sinne ist der Product Owner keine klassische Führungskraft, sondern agiert als dienende Führung, die sich um die Zielbestimmung kümmert. Die Rolle des Product Owners stellt sicher, dass immer und zu jeder Zeit klar ist, was umgesetzt werden soll. Damit schafft die Rolle die Orientierung, die ein selbstorganisiertes Team benötigt, um in die konkrete Umsetzung gehen zu können. Die Rolle des Product Owners kümmert sich intensiv darum, dass die Kommunikation mit den Anspruchsgruppen des Projekts rund läuft, die Informationen vom Scrum-Team zum Management (zum Beispiel der Amts- und Dezernatsleitung), dem Auftraggeber (zum Beispiel Verwaltungsausschuss oder Gemeinderat) und in Gegenrichtung funktioniert. Da die Rolle auf das WAS fokussiert ist, bleibt das WIE klar und eindeutig beim Umsetzungsteam.

Vom Product Owner wird daher eine hohe kommunikative Fähigkeit abverlangt, die zugleich sehr guter Kenntnisse des Projektumfelds (Entscheider, Entscheidungsprozesse, Rahmenbedingungen u. ä.) bedarf. Product Owner sind daher Generalisten, die gut und genau einschätzen können, was Auftraggeber, Management und Ergebnisanwender benötigen und brauchen. Die Rolle sollte daher von Personen ausgefüllt werden, die über entsprechende Kenntnisse und Erfahrungen verfügen, gleichzeitig auch ein ausgeprägtes Fingerspitzengefühl für Kommunikation aufweisen.

Kleine Anmerkung am Rande: Scrum ist – wie an dieser Stelle sichtbar wird – kein Wunschkonzert der Teammitglieder, sondern es richtet sich alles nach den Bedarfen und Wünschen des Auftraggebers aus. Am Ende muss ein Ergebnis vorliegen, mit dem die „Kunden“ des Teams arbeiten können und wollen.

UMSETZUNGSTEAM

Das WIE der Umsetzung entscheidet das Umsetzungsteam (Entwicklungsteam). Der Scrum-Leitfaden beschreibt die Rolle wie folgt:

Das Umsetzungsteam besteht demnach aus Experten. Fachleuten in genau den Gebieten, die benötigt werden, um ein Thema zu entwickeln. Entwickeln bedeutet in diesem Sinne, dass am Ende jeder Iteration (Sprint) ein fertiges „Teilergebnis“ vorliegt, das bereits einen echten Mehrwert erzeugt und verwendet werden kann. Zentrale Annahme ist – wie bei allen agilen Ansätzen –, dass die Fachleute selbst am besten wissen, wie sie ihre Aufgaben angehen. Man lässt ihnen die Freiheit selbst zu entscheiden, wie sie die gesetzte Aufgabenstellung im Sinne des definierten Auftrags in die Umsetzung bringen. Niemand gibt dem Team vor, wie es die Aufgaben zu erledigen hat, sondern es wird lediglich das WAS (siehe Rolle des Product Owners) definiert.

Entsprechend schreibt der Scrum-Leitfaden Umsetzungsteams folgende Eigenschaften zu:

Die deutschsprachige Fassung des Scrum Guides spricht von „interdisziplinären Teams“. Wir nutzen im Forum Agile Verwaltung dennoch gerne den angelsächsichen Begriff „crossfunctional“, da die Teams nicht einfach „nur“ interdisziplinär sind, sondern spezifischer auf die notwendigen Funktionen zur Erfüllung der Aufgabe abzielend zusammengesetzt werden.

Innerhalb des Entwicklungsteams gibt es keine weitere Rollenunterteilung. Die Idee ist, dass grundsätzlich alle Mitglieder es Entwicklungsteams alle Aufgaben innerhalb der Umsetzung mittragen und miterledigen. Dies bedeutet nicht, dass es innerhalb des Teams keine Spezialisierungen geben darf. Viel mehr wird hier das sogenannte „t-shaphed“-Modell angestrebt, nach der jedes Teammitglied grundsätzlich in der Lage sein sollte, alle Aufgaben zu unterstützen, und ein solides Basiswissen haben sollte, das durch eine Spezialistensäule mit vertiefenden Kenntnissen ergänzt wird. Ziel ist es dabei, dass alle Teammitglieder in der Lage sind, sich gegenseitig zu unterstützen und ggf. auch einen temporären Ausfall eines Teammitglieds zu kompensieren.

Bei der Zusammenstellung eines solchen Teams sollten neben der fachlichen Eignung unbedingt auch auf die soziale Kompetenz der Teammitglieder geachtet werden. Die Mitglieder des Umsetzungsteams müssen ausgesprochene Teamplayer sein (dies gilt übrigens auch für die anderen Rollen). Dennoch: Gerade bei neu zusammengestellten Teams, unabhängig davon, ob sie über Scrum-Erfahrung verfügen oder nicht, dauert es eine Weile, bis sich das gegenseitige Verständnis herauskristalliert hat. Hier ist die Rolle des Scrum Masters von zentraler Bedeutung, die dabei unterstützend wirkt.

SCRUM MASTER

Die Rolle des Scrum Masters wird meines Erachtens in der Praxis noch viel zu oft unterschätzt. Das Ausfüllen dieser Rolle braucht mehr als nur zweitägiges Zertfizierungsseminar zum Scrum Master. Sie setzt ein enorm hohes methodisches, fachliches und soziales Wissen und Können voraus. Warum ergibt sich aus der „Aufgabenstellung“, die der Scrum-Leitfaden sehr dezidiert und ausführlich definiert. Der Scrum-Leitfaden definiert die Rolle des Scrum Masters wie folgt:

Der Scrum Leitfaden beschreibt diese Aufgabe – in Bezug auf die Organisation – wie folgt:

Die Rolle des Scrum Master unterstützt den Product Owner laut Definition des Scrum-Leitfadens …

Zu guter Letzt, unterstützt die Rolle des Scrum Masters auch das Umsetzungsteam (Development Team) und zwar nach Scrum-Leitfaden wie folgt:

Hieraus lässt sich folgendes bereits ableiten: Die Rolle des Scrum Masters ist nicht nur die Moderation der verschiedenen Scrum-Ereignisse wie Daily, Retrospektive und Review. Ganz im Gegenteil. Hier hat die Rolle bestenfalls „nur“ eine unterstützende Funktion. Die Rolle beinhaltet insbesondere „Wissensvermittlung“ und „Veränderungsbegleitung“. Es ist Aufgabe, den Teammitgliedern und allen, die mit dem Team zu tun haben, also auch der Führung, den anspruchsberechtigten Personen der Organisation um das Team herum zu vermitteln, was Scrum ist. Zugleich ist es Aufgabe dieser Rolle, das Team und Umfeld methodisch in seinen Aufgaben zu unterstützen und Hilfestellung dabei zu bieten, interne Hindernisse im Team aufzulösen. Das bedeutet eben auch eine hohe methodische Kompetenz im Hinblick auf Produktivitätshindernisse und deren Auflösung. In dieser Funktion ist ein Scrum Master weit mehr als Moderator der jeweiligen Teamevents.

Dazu gehören auch Themen und Fragestellungen, die sich nicht originär aus dem Scrum-Leitfaden ergeben. Fragen, wie z. B. die Bedeutung von Crossfunktionalität und Selbstorganisation für das Gelingen von Scrum. Hieraus resultieren wiederum Fragen, wie sich die Umsetzung innerhalb des Teams in die Organisation ermöglichen lässt, aber auch, was dies für Führungskräfte im Hinblick auf ihre Aufgabe bedeutet. Der Scrum Master wirkt innerhalb der Organisation als „Veränderungsbegleitung“, die die permanente Weiterentwicklung der Scrum-Implementierung in die eigentliche Organisation unterstützt. Im Fokus steht nicht der mahnende Zeigefinger, sondern die Herstellung eines gemeinsamen Verständnisses über die „Notwendigkeiten“. Nicht aus Jux und Tollerei oder weil agiles Arbeiten gerade modern und hipp ist, sondern weil das Ziel ist, am Ende bessere Ergebnisse zu erzielen. Agilität ist kein Selbstzweck. Sie dient immer der Verbesserung der Prozesse mit dem Ziel, die Ergebnisse ständig und permanent zu verbessern.

Wer auch immer diese Rolle innehat, muss daher ein sehr gutes Verständnis der Organisations- und Führungsstrukturen aufweisen. Zugleich braucht es ein tiefes Verständnis über Veränderungsprozesse, denn die Integration eines selbstorganisierten Teams in bestehende Strukturen zieht erhebliche Veränderungen an den Schnittstellen nach sich, die alles andere als banal sind. Es kommt zwangsläufig zu Reibungskonflikten, die viel Wissen über Konfliktsituationen und deren Auflösung voraussetzt. Dies sind Kompetenzen, die einiges an Erfahrung voraussetzen.

Im Fokus steht die Befähigung zum organisatorischen Lernen innerhalb eines Entwicklungsprojekts. Scrum ist ein Managementframework, dass den Rahmen für die Entwicklung von Projekten schafft, die durch hohe Komplexität geprägt sind. Dafür braucht es auch um das Projekt herum das passende Verständnis, den erforderlichen Rahmen, damit das Projekt erfolgreich sein kann. Dies schließt auch die Personen ein, die selbst nicht direkt Teil des Projekts sind, sondern Teil der umgebenden Organisation sind. Hier zeigt sich, die Aufgabe ist nicht trivial. Ganz im Gegenteil. Die Rolle mit Leben zu füllen ist zentral für den Erfolg des Teams. Sie lässt sich nicht als „Nebenjob“ ausüben. Und sie setzt hohes Können und Wissen voraus. Zugleich braucht es eine hohe Akzeptanz der Person in der Rolle innerhalb der Organisation. Um die Rolle ausüben zu können, braucht es „Zeit“ in Sinne von Freiraum, um auf Bedarfe reagieren zu können. Daher ist Scrum Master keine Rolle, die „zusätzlich“ gelebt werden kann. Der Rolleninhaber sollte, um nicht in Rollen- und Zielkonflikte zu geraten, im Team selbst ausschließlich und fokussiert auf eine einzige Rolle, nämlich die des Scrum Masters tätig sein. Auch wenn die Versuchung groß ist, ist die strikte Trennung sehr wichtig.

Gute Scrum Master helfen „Knoten“ zu lösen und sind damit ein zentraler Erfolgsfaktor, um ein Scrum-Team zum „Fliegen“ zu bekommen.

ERWEITERUNG DES ROLLENMODELLS

Leider bezieht sich der Scrum-Leitfaden ausschließlich auf das Scrum-Team. Hilfreich ist es daher, das Rollenmodell von Scrum, um drei weitere Rollen zu erweitern, um die Schnittstellen des Scrum-Teams besser zu verorten.

Damit ein Scrum-Team erfolgreich arbeiten kann, braucht es die Unterstützung des Managements, also der Führungskräfte (Behördenleitung, Amtsleitung, Fachbereichsleitung u. ä.). Wie sprechen zwar von selbstorganisierten Teams, aber nicht von führungslosen Teams. Auch selbstorganisierte Teams brauchen Führung. Führung im Sinne von Schaffung der Rahmenbedingungen und Definition der strategischen und taktischen Zielsetzung der Organisation. Scrum-Teams sind operativ tätig. Hierauf liegt ihr Fokus. D. h. selbstorganisierte Teams schaffen Führung nicht ab, sondern der Fokus der Führung richtet sich auf ihre originäre Kernaufgabe. Die Führung kümmert sich darum, dass die Rahmenbedingungen vorhanden sind, die das Projektteam braucht, um arbeiten zu können. Deswegen ist der regelmäßige Austausch in beiden Richtungen von der Führung ans Team und vom Team an die Führung mit ein wesentliches Element für das Gelingen selbstorganisierter Teams. An dieser Stelle möchten wir anmerken, dass wir gerade in den Kommunalverwaltungen auch die Gemeinderäte als Teil der Führung sehen.

Da Auftraggeber, Anwender und Management nicht immer identisch sind, macht es Sinn, als weitere Rolle den Auftraggeber im Sinne von Geldgeber und Initiator einzuführen. Der Auftraggeber ist der Finanzier des Projekts. Diesen regelmäßig zu informieren, aber auch mit seinen Interessen entsprechend zu würdigen, dürfte ohne weitere Erklärung für jeden nachvollziehbar sein. In dieser Rolle finden wir regelmäßig die „politischen Entscheidungsträger“ wie z. B. den Gemeinderat. Bei kleineren Projekten kann dies auch die Verwaltungsspitze bzw. Behördenleitung sein.

Da in vielen Projekten die Anwender, also diejenigen, die am Ende mit dem Ergebnis des Projekts arbeiten, nicht deckungsgleich mit Auftraggeber und Management sind, bietet sich die Unterscheidung in eine entsprechende dritte Rolle an. Für den Prozess der Projektentwicklung sind diese insofern zentral, weil sie das Feedback liefern, dass das Umsetzungsteam benötigt, um Verbesserungen vornehmen zu können. Anwender können bei internen Projekten Verwaltungskollegen und Leistungsempfänger sein.

Alle drei Rollen repräsentieren relevante Interessengruppe eines Scrum-Teams, die es zu berücksichtigen gilt und die nicht minder zum Erfolg des Projektes beitragen. Wie bereits erwähnt, kann es hier zu Überschneidungen und Überlappungen kommen. Aber eben nicht zwangsläufig. Daher halten wir die Erweiterung des Scrum-Rollenmodells um diese drei „externen“ Rollen für hilfreich und zielführend, um verorten zu können, wer in die Kommunikation bedarfsgerecht eingebunden werden sollte.

FAZIT

Es ist hoffentlich gelungen, zu zeigen, dass Scrum zwar mit einem einfachen Rollenmodell auskommt, aber die jeweilige Rolle nicht zu unterschätzen ist. Auch wenn angesichts enger Personalkapazitäten in den Amtsstuben die Versuchung groß ist, die einzelnen Rollen durch Doppelfunktionen zu vereinen oder die Aufgabe der jeweiligen Rolleninhaber als „Zusatz“ zum Tagesgeschäft zu definieren, sollte man den Verlockungen und dem Druck nicht allzu leichtfertig nachgeben. Insbesondere der Scrum Master ist eben mehr als „nur“ ein Moderator der Scrum-Prozesse. Der Scrum-Leitfaden definiert diese drei Rollen nicht aus normativen Wunschvorstellungen heraus, sondern alle drei Rollen sind das Ergebnis eines langen, empirischen Beobachtungsprozesses. D. h. sie haben sich auf Basis von praktischen Beobachtungen herausgebildet und sind damit auch eindeutig begründbar. Das Zusammenspiel der drei Rollen ist ein zentraler Baustein für das Gelingen selbstorganisierten Arbeitens in Scrum-Projekten. Die empirische Evidenz der drei Rollen spiegelt sich übrigens auch darin wider, dass nahezu alle weiteren agilen Ansätze wie z. B. Kanban (sehr gut geeignet, um den „Linienalltag“ agiler zu gestalten) ebenfalls vergleichbare Rollen nutzen, die ähnliche Funktionen und Aufgaben wahrnehmen.

Weiter zeigt sich: Selbstorganisation ist kein Selbstläufer. Sie setzt eine hohe und breite Methoden- und Fachkenntnis aller Beteiligten mit ausgeprägten sozialen Kompetenzen voraus, damit diese gelingen kann. Gelingt es diesen Weg zu beschreiten, ist es allerdings eine sehr lohnende Investition, weil die Ergebnisqualität permanent verbessert und weiterentwickelt wird. Agilität ist kein Selbstzweck. Sie dient immer der Verbesserung und Weiterentwicklung der Ergebnisqualität für alle Beteiligten. Für die Mitarbeiter, die Führung, den Auftraggeber und den Anwender!