Wenn man Scrum näher studiert, wird deutlich, dass es mehr als drei Rollen darin gibt. Zwar beschreibt das Scrum-Framework explizit die Tätigkeiten und Verantwortlichkeiten von ScrumMaster, Product Owner (PO) und dem Team. Doch befinden sich alle drei in einem eingebetteten Ökosystem von weiteren Rollen, dem Management, den Stakeholdern und Benutzern. In der herkömmlichen Scrum-Literatur, die es für 20-40 Euro in jedem Buchladen tonnenweise zu kaufen gibt, wird kaum auf deren Rechte und Pflichten eingegangen. Ich habe jedoch festgestellt, dass es ohne die Einhaltung der Pflichten und die Unterstützung dieser Menschen kein erfolgreiches Projekt oder Produkt mit Scrum geben kann.

Es kann sein, dass manche hier beschriebenen Pflichten von Stakeholdern im konkreten Fall auf das Management oder den PO zutreffen, zum Beispiel, wenn es keine Stakeholder in diesem Sinne gibt. Das ist bei internen Projekten oft der Fall. Es mag auch andere Fälle geben, wo diese Überlappung auf andere Rollen zutrifft. Es ist aber essentiell wichtig, dass man versteht, dass dabei diese verschiedenen Rollen weiter existieren und sich nur in Personalunion überlagern. Scrum trennte den alten Projektleiter in die zwei Rollen ScrumMaster und Product Owner (und eigentlich disziplinarisch auch in das Management) auf, um genau diese Ambiguitäten und inneren Dissonanzen zu klären. Diesem Ansatz sollten wir folgen, um Scrum besser zu verstehen.

Benutzer und Stakeholder

Zunächst ist nämlich zu klären, woher überhaupt dieses ominöse Projekt-Budget stammt. Dafür muss es ja sicherlich irgendwann eine Art Business-Case gegeben haben, den sich irgendjemand ausgedacht und ausgerechnet hat. Wenn der Wert eines Projekts oder Produktes entsteht, dann doch sicherlich durch einen Nutzen, den jemand zu bezahlen bereit ist. Und wo es einen Nutzen gibt, gibt es folgerichtig Nutzer. Ohne deren Existenz und Bedarf am Mehrwert gibt es schlichtweg keine Entwicklung, sei es nun durch ein Projekt oder ein Produkt. Daher nehmen die Nutzer, genauergesagt Benutzer, eine berechtigte Rolle ein.

Außerdem gibt es jemanden, der aktive oder potentielle Benutzer in irgendeiner Weise kennt beziehungsweise deren Existenz vermutet. Er beschließt, deren Bedarf am Mehrwert zu decken und daran Geld zu verdienen. Er hat auch den Business-Case durchgerechnet und kann den Erfolg des Projekts am besten beurteilen. Er betreibt vielleicht Crowdfunding zur Start der Finanzierung, vielleicht holt er sich das Geld aber auch von einem Investor oder seinem eigenen Management ab. Dazu musste er den Businessplan vielleicht sogar öffentlich präsentieren. Vielleicht sind es mehrere Leute, zum Beispiel ein Consortium oder eine (eigene) Geschäftleitung, auch eine eigens dafür gegründete Firma in Gänze. In der Scrum-Literatur wird diese Gruppe von Menschen als Stakeholder bezeichnet.

Der Product Owner ist die Verkörperung der Stakeholder gegenüber dem Team. Eventuell ist er dabei eigenmächtig, eventuell aber nur Wasserträger von Informationen grauer Eminenzen. Für das Scrum Framework spielt das kaum eine Rolle, weil ein guter Product Owner dies theoretisch transparent machen kann. Aber wir wollen uns ja mit der Praxis und nicht mit der Theorie beschäftigen, also ist auf auch die Stakeholder einzugehen.

Management

Mit dem Begriff “Management” wird immer die Führungsetage des Teams beschrieben, also nicht die der Benutzer oder der Stakeholder. Das Management des Teams kann gleichzeitig PO oder Stakeholder sein, wenn es sich um einen internen Auftrag handelt. Aber wir wollen hier ja sauber bleiben und nur diesen Teil betrachten, der spezifisch für das Management selbst steht. In der Scrum-Literatur wird bereits über zwei Pflichten des Managements gesprochen, aber nur indirekt, quasi im  Kleingedruckten. Wer kennt nicht solche Sätze wie “The management must empower the product owner” oder “Impediments should be solved with the help of the management”. Wie aber kann das Management dies tun, wenn es ihm niemand vorher ankündigt, dass es eine Rolle im Projekt einnimmt und welche Pflichten mit dieser Rolle einhergehen? Und hat jemand schon mal ein Kärtchen “Management” an Scrum-Boards gesehen? Ich möchte diese zwei Pflichten unten auch explizit vorstellen.

Rechte und Pflichten

Wer als ScrumMaster, Projekt-Coach oder in einer Transitionsphase als “alter” Projektmanager erfolgreich Scrum für Projekte oder eine Produktentwicklung einsetzen möchte, sollte diese drei weiteren Rollen kennen und deren Befindlichkeiten beachten. Nicht selten lauert der größte Widerstand wie immer im emotionalen Bereich und außerhalb des Scrum-Frameworks. Ich möchte Euch dies anhand von den Pflichten, den Rechten, den Verboten und einiger Fragen zu den Rollen deutlich machen. Wir fangen dabei mit den einfachen Sachen an und arbeiten uns dann an den Kern des Problems vor.

Dabei müssen wir uns das Wesen von Scrum nochmals deutlich vor Augen halten: Scrum ist die Verkörperung von “Effektivität über Effizienz”, es ist eine Iteration über die berühmte 80/20-Regel (das Pareto-Prinzip). Es ist die Projektmanagement-Methodik des Deming-Cycle (ein immer wiederkehrender Kreis von Aktion und Feedback, um sich fortlaufend anzupassen und zu verbessern). Scrum lebt vom schnellem Feedback, der Transparenz und der Retrospektive. Damit gerüstet, nun zu den Pflichten der Rollen selbst.

Pflichten der Benutzer

Die wichtigste Aufgabe des Benutzers ist also, Feedback über die Produktqualität in einer Geschwindigkeit zu geben, die eine Anpassung des Produkts direkt im nächsten Sprint erlaubt. Wenn das nicht sichergestellt ist, so kann die nächste Version nicht besser werden als es die letzte war! Und spätes Feedback mag zu spät sein (Architekturentscheidungen etc.)! Es sind dafür einige Voraussetzungen nötig.

Fragen: Wie schnell erreicht mein Produkt einen Benutzer? Erst nach einem Release? Und wie leicht mache ich es einem Benutzer, Feedback zu geben? Möglicherweise Inline, also im Produkt selbst? Wie lange dauert es vom ersten Moment eines Bugfix, bis jemand das OK am Ende der Leitung geben kann? Es ist fast eine Aufgabe des Teams, dieses Feedback sicherzustellen, und es ist eine der einfacheren Übungen, weil es das Team in den meisten Fällen selbst tun kann. Das Team benötigt eventuell die Hilfe von PO oder Stakeholdern, um mit den echten Benutzern in Kontakt zu kommen, kann aber technische Voraussetzungen schaffen (Chat, Kontakt-Formulare, Telkos, Foren).

Frage dich: Sind die wirklichen Benutzer mit einbezogen? Der Product Owner kann natürlich selbst entscheiden, ob das Produkt dem Benutzer so oder so besser gefallen würde. Er kann auch die Stakeholder fragen. Dennoch ist es eine schlechte Idee, wenn der Product Owner die Rolle der End-Benutzer vergisst, und sein Business Case (oder der der Stakeholder) wird sich in der Realität eventuell nicht rechnen. Eine gute Idee wäre zum Beispiel, einen Pilotkunden mit ins Boot zu holen.

Pflichten der Stakeholder

Die Stakeholder haben als zweite Hauptpflicht die Aufgabe, den Projekt-Erfolg zu messen und als Feedback dem PO zur Verfügung zu stellen. Nur sie können den Projekt-Erfolg sauber mit dem Business Case vergleichen und über Hop oder Top entscheiden.

Die Stakeholder haben weiter die Pflicht, die Fachkenntnisse des Teams zu respektieren und nicht in das Wie der Implementierung einzugreifen. Das fällt einigen bereits schon sehr schwer, da es ein explizites Verbot ist und viele sich berufen fühlen, die technische Ausgestaltung aktiv mitgestalten zu wollen. Zurücklehnen und das Team tun lassen! Das entspannt!

Die Stakeholder haben keine Rechte, das Produkt selbst zu bewerten! Wann immer sie es tun, werden sie die echten Benutzer übergehen. In einer Personalunion sollte man sich dessen bewusst sein. Das gilt übrigens auch für den PO. Er sollte das Feedback der Nutzer (Produktqualität) und Stakeholder (Produkterfolg) einholen und für seine Entscheidungen nutzen, aber niemals behaupten, er könne dies selbst entscheiden, wenn er nicht selbst aktiver Benutzer oder Vermarkter ist.

Fragen: Wie viele Stakeholder meinen, sie können die Qualität des Produkts bewerten? Wie viele Investoren schreiben explizit neue Funktionen für kommende Releases als zwingend vor? Kann dann der PO wirklich verantwortlich für den Projekterfolg sein? Vertrauen dann die Stakeholder dem PO? Wie viele Stakeholder haben Kontakt zu End-Benutzern? Wie viele kennen deren Wünsche und Anliegen? Wie viele von ihnen prüfen den Business Case so häufig, um Feedback rechtzeitig für den nächsten Sprint zur Verfügung stellen zu können?

Pflichten des Managements

Das Management des Teams hat besondere Pflichten. Denn es stellt erst einmal das Team überhaupt zur Verfügung, daneben auch Zeit, Räume und Materialien. Nicht selten müssen für neue Projekte auch spezielle Geräte angeschafft oder Kosten von Dienstleistungen übernommen werden. Das Management stellt dabei den organisatorischen Rahmen für die Arbeit des Teams sicher und schützt es vor Anlenkungen Dritter (zB im Multi-Projektmanagement). Das ist eigentlich bereits die Hauptaufgabe des Managements.

Die zweite in der Literatur erwähnte Pflicht ist die Beseitigung von Impediments, also Hindernissen. Eigentlich ist es gar keine eigenständige Pflicht, es ist meines Erachtens nur eine Aufgabe, um die erste Regel nach einem Defekt wieder herzustellen: Neues Material besorgen, Literatur kaufen, Schulung durchführen, Raumumzug, neues Team-Mitglied, Rechner-Updates, eine Konfliktlösung oder ähnliches.

Die meist explizit beim PO als “Entscheidungs-Recht” angelegte Regel bedeutet hier: Das Management hat die Pflicht, den PO entscheidungsfähig zu machen!

Außerdem muss es ebenso wie die Stakeholder davon Abstand nehmen, dem Team in das Wie reinzureden. Sehr schwer!

Fragen: Wie viele Chefs behaupten nicht, die Architektur mitbestimmen zu müssen? Wie viele Vorstände geben Tools und Frameworks vor? Wird dem PO auch mal von oben über den Mund gefahren, wenn eine kleine “Kurs-Korrektur” ansteht? Wie viele Chefs tun sich schwer, mobile Endgeräte zu kaufen, obwohl ein Tag Consulting zum gleichen Preis an den Kunden verkauft wird? Wer kümmert sich aktiv um Konfliktlösungen? Oder heißt es oft: Klärt das unter euch?

Rechte

Natürlich gehen alle Rollen auch einher mit Rechten. Meiner Meinung nach ist jede Pflicht auch als Recht zu verstehen: Der Stakeholder darf den Projekterfolg bestimmen, der PO darf über den Inhalt bestimmen, das Management darf die Verantwortung an den PO übertragen. Jeder sollte auch immer das Recht haben, alle Informationen zum Projekt erfragen zu können, um zu wissen, wo wir gerade stehen.

In einer transparenten Projektwelt wie Scrum ist vor allem aber eines wichtig: Jeder vertraut auf die Fähigkeiten des anderen, seine Rolle gut ausüben zu können. Kritik und Feedback können aber nicht nur dem Produkt gelten, sondern auch der Ausübung einer bestimmten Rolle oder dem Arbeitsprozess. Schließlich gilt es, auch selbst iterativ zu lernen und immer besser zu werden. Als Programmierer, PO, Team-Mitglied und Mensch mit sozialer Verantwortung.