Wieso Scrum Rollen gestärkt werden müssen
Als Ken und Jeff Scrum in den 90ern erfunden haben, arbeiteten sie nicht für kleine, auf IT spezialisierte Startups. Sie arbeiteten in mittleren bis großen Betrieben, in denen schon damals die Probleme mit Legacy und Scale bekannt waren, die auch heute noch in vergleichbaren Unternehmen existieren. Wenn man den Scrum Guide liest, fallen einem ein paar Dinge auf. Es gibt keine Projektmanager, weil es bei Scrum darum geht, Produkte auf eine Art zu entwickeln, die nichts mit Projektmanagement oder gar Projekten zu tun hat. Einem fällt auch auf, dass zwar Stakeholder genannt werden, doch auch sie spielen in der eigentlichen Produktentwicklung keine Rolle – außer, dass sie ihre Wünsche an den Product Owner herantragen und beim Review Feedback geben.
Es existieren keine komplizierten Management-Strukturen außerhalb des Teams, doch die Stakeholder könnten sowohl innerhalb als auch außerhalb der Organisation sein. Es gibt keine Produktmanager oder Business Owner bei Scrum. Der Product Owner ist derjenige, der all die Aufgaben erfüllt, die diese beiden in anderen nicht auf Scrum basierenden Szenarien ausführen würden. Der Scrum Guide besagt ganz klar: „Damit der Product Owner erfolgreich sein kann, muss die ganze Organisation seine Entscheidungen respektieren.“ Es ist tatsächlich eine sehr leitende, mächtige Rolle. Er ist die einzige Person, die Verantwortung für alle produktbezogenen Entscheidungen trägt und die wichtigste Methode, um den finanziellen Erfolg des Produkts sicherzustellen liegt im Besitz des Product Backlogs. Bitte behalten Sie im Hinterkopf, dass jedes Produkt nur einen Product Owner hat, der eher unternehmens- als technisch orientiert ist.
Der Scrum Master sollte gleichermaßen bevollmächtigt sein. Aus Sicht des Unternehmens muss er mindestens auf der gleichen Stufe wie ein Projektmanager in vergleichbaren, nicht auf Scrum basierenden, Produktentwicklungsszenarien sein. Dieser Rang ist jedoch gänzlich anders ausgedrückt, als bei traditionellen Managern. Scrum Manager halten sich stark an die Auffassung, die als „Servant Leadership“ bekannt ist. Sie bieten drei verschiedenen Parteien Dienste an: Dem Entwicklerteam, dem Produkt Owner und dem Unternehmen. Um diese Dienste anbieten zu können, müssen sie vom Unternehmen auch dazu befähigt werden. Sie müssen im Zusammenhang mit dem Team als die wichtigste Kontaktperson in einer Art Management-Rolle angesehen werden. Es darf niemandem „über“ dem Scrum Master geben, der Entscheidungen über Prozesse oder das System, in dem das Team arbeitet, trifft. Diese Entscheidungen können nur vom Scrum Team mit Hilfe des Scrum Masters getroffen werden. Grundsätzlich sollte der Scrum Master in alle Aktivitäten involviert sein, die nicht expliziet den Produkt Owner oder das Entwicklerteam betreffen.
So wie es dem Product Owner schwer fällt, seine Aufgabe gut zu machen, wenn zwischen ihm und seinen echten Stakeholdern (und damit meine ich viel mehr tatsächliche Endnutzer, als irgendeine Produktmanagement-Gruppe) eine gewisse Distanz oder sogar eine Mauer steht, so ist der Scrum Master sogar noch mehr auf die Verbindungen und Beziehungen angewiesen, die er mit anderen im Unternehmen in vielen Abteilungen und auf unterschiedlichen Ebenen aufbaut. Bei Meetings, die im Zusammenhang mit dem Prozess oder System der Entwicklung stehen und das Team betreffen, muss der Scrum Master anwesend sein. Das gilt auch für Diskussionen, die das Budget betreffen (ein guter Ansatz ist es, den PO für das Geld, das reinfließt verantwortlich zu machen, da er auch für die Maximierung des ROI verantwortlich ist und den Scrum Master für die Kostenüberwachung verantwortlich zu machen), Verträge, Preisstrategien, Einstellungen und HR-Richtlinien im Allgemeinen, Priorisierungen auf Portfolio-Level (die eventuell auch den PO erfordern) und alles, das im Zusammenhang mit der Unternehmenskultur steht. All diese Dinge werden anders gemacht, wenn ein Unternehmen sich für die agile Produktentwicklung entscheidet, was bedeutet, dass der Scrum Master im Wesentlichen lahm gelegt wird, wenn er nicht auf all diesen Ebenen mit einbezogen wird. Das Team wird keine Selbstorganisation oder die Fähigkeit, sich zu verbessern, entwickeln. Wenn der Scrum Master davon abgehalten wird, die oben genannten Dienste innerhalb der Organisation auszuführen, dann wird diese auch nicht die Vorteile sehen, die sie sich von Agile erwartet hat.
Ein Kollege hat mich vor kurzem gefragt, ob ich die Rolle des PO so beschreiben könnte, wie er sie bei einem unserer Kunden vorfinden würde. Er hatte den CSPO Kurs absolviert und den Test bestanden, aber noch nicht viel Erfahrung in agilen Projekten gesammelt. Im Normalfall würde jemand erwarten, dass die Rolle so ist, wie sie im Scrum Guide definiert ist und ich denke, zum Großteil stimmt das auch. Es gibt jedoch viele Varianten, wie die Scrum-Rolle tatsächlich gelebt wird. Manche davon sind berechtigt, manche nicht. Beispielsweise muss der Kontext, den die beiden Autoren des Scrum Guides im Kopf hatten berücksichtigt und mit den Umständen in einer typischen Firma, die Scrum nutzt, verglichen werden.
Manche Unternehmen behaupten von sich anders oder besonders zu sein und halten es für notwendig, Dinge zu tun, die entweder absichtlich oder auch unabsichtlich den PO oder SM in ihren Rollen entmachten. Ich habe dem oben genannten Kollegen beispielsweise erklärt, dass seine Rolle in dem Unternehmen, mit dem er arbeiten wird, wahrscheinlich sehr anders ausfallen wird, als im Scrum Guide beschrieben. Es kommt häufig vor, dass ein Product Owner zu einem bereits angelaufenen Projekt hinzustoßen und feststellen wird, dass sein Job bereits erledigt wurde. Jemand anderes – vielleicht der Product Manager oder Business Owner – hat bereits eine Vision für das Produkt entwickelt und erhebliche Anteile der Konstruktionsunterlagen existieren vielleicht bereits, inklusive Screen Shots. Das einzige, was noch zu tun bleibt, ist, dass die Programmierer das Produkt als Quellcode schreiben. Aber weil das Unternehmen sich für Scrum entschieden hat, brauchen sie einen PO und seine Hauptaufgabe liegt dann darin, diese Dokumentation in „User Stories“ zu verpacken und in ein Tool wie Jira einzuspeisen. Selbst die Prioritäten der Features wurden wahrscheinlich schon entschieden. Das ist totale Verschwendung. In diesem Kontext ist es bereits viel zu spät für einen Product Owner, User Stories und Scrum selbst. Scrum wäre für die Teammitglieder wichtig gewesen, die die Konstruktionsunterlagen geschrieben haben; die Gruppe also, die das Produkt tatsächlich entwickelt hat.
Auch für User Stories ist es zu spät. User Stories wären irgendwo zwischen der Vision und der Erstellung der Konstruktionsunterlagen relevant gewesen. Diese Konstruktion in User Stories zu übertragen, bedeutet letztlich nur, Informationen wegzuschmeißen oder einen Schritt rückwärts zu gehen. Die Entwickler sollten direkt von der Konstruktion her arbeiten, wenn sie schon existiert; sie in User Stories zu überführen bringt keinerlei zusätzlichen Nutzen. Selbst Scrum kommt jetzt zu spät. Das Produkt wurde bereits entwickelt. Die Entwickler sollten es einfach runterschreiben, Feature um Feature.
Es sind genau solche Unternehmen, die gern auch mal Rollen wie die des Projektmanagers oder „IT-PO“s zum Team hinzufügen, um beispielsweise End-to-End-Prozesse, Compliance- und Steuerungsfunktionen oder auch das Kostencontrolling zu verantworten. Diese Rollen werden als die Haupt-Managementrollen angesehen, mit denen Leute außerhalb des Teams agieren werden, wodurch der Scrum Master außen vor bleibt und auf eine Art Teamassistenz-Rolle zurückfällt und für nicht viel mehr bekannt sein wird als die Organisation von Meetings.
Scrum ist für sehr komplexe, hoch-kreative, marktorientierte Produktentwicklungs-Bestrebungen gemacht und bezieht sowohl unternehmerisch orientierte als auch technische Mitarbeiter mit ein. Das ist der Grund, warum äußerst befähigte Product Owner und Scrum Master benötigt werden. Doch wenn Scrum nicht so eingesetzt wird, wie vorgesehen und wie in den vergangenen Absätzen beschrieben, dann wird auch keine der beiden Rollen benötigt, geschweige denn Scrum selbst. All die komplizierten, kreativen Arbeiten wurden bereits erledigt!
Um fair zu bleiben: Ich denke, dass die Scrum Community die Skills, die ein Scrum Master wirklich mitbringen muss, um seinen Job richtig auszuführen, möglicherweise unterschätzt hat. Ich stelle fest, dass viele vor Diskussionen über Geld zurückschrecken oder sich unwohl dabei fühlen, mit Leuten außerhalb der IT, vor allem Managern, umzugehen. Manchmal sind auch die Scrum Master selbst ein bisschen zu sehr auf die grundsätzlichen Richtlinien im Scrum Guide fixiert und denken, dass ihr Rolle nicht viel mehr beinhaltet als Meetings zu planen und unendliche auf Post-Its basierende Diskussionen mit den Programmieren über Werte und Prinzipien zu führen oder mit Lego zu spielen. Nicht, dass Sie mich falsch verstehen: All diese Dinge gehören zu den Aufgaben des Scrum Masters und sind wichtig. Es gibt mit Sicherheit Zeiten für diese teamorientierten Coaching-Aufgaben, aber ich denke, im Allgemeinen sollte ein Scrum Master bessere Arbeit leisten, um zu wissen, wann solche Dinge und wie viel davon, angebracht sind. Ich denke, darin liegt einer der Gründe, weshalb Unternehmen das Vertrauen in Scrum Master verlieren und es als notwendig ansehen, seltsame Strukturen und zusätzliche Rollen ins Leben zu rufen, die dann die Aufgaben ausfüllen sollen, die der Scrum Master scheut. Dieser Verlockung muss jedoch wiederstanden werden, weil das Unternehmen keinen großen Nutzen in Agile oder Scrum finden wird, wenn diese beiden entscheidenden Rollen entmachtet bleiben – und das Team so nie Selbstorganisation erreichen wird.
