Scrum
Scrum Sprint Länge: Warum 1 Woche effektiver ist
Was ist die optimale Scrum Sprint Länge? Die überraschende Erkenntnis: 1-wöchige Sprints sind effektiver! Lese hier warum.
Was macht die Rolle des Product Owners so problematisch und wie sollte sie angelegt sein, um eine agile Transformation erfolgreich werden zu lassen?
Das erste, was Organisationen, die agiles Arbeiten und Scrum als Methode einführen wollen, oft in den Sinn kommt, ist das Besetzen der Rollen. Dass agiles Arbeiten viel mehr bedeutet, als Rollen zu besetzten, Sprints und Meetings einzuführen und dass viele Organisationen leider agiles Arbeiten auf diese Dinge reduzieren und hier stoppen, haben wir an anderer Stelle schon hinreichend diskutiert. Hier mehr zum Thema.
Aber schon bei der Definition und Besetzung der Rollen tauchen die ersten Probleme auf, die – wenn sie nicht frühzeitig adressiert werden – weitreichende Konsequenzen auf den gesamten Prozess haben werden.
Die dabei problematischste Rolle ist zweifelslos die Rolle des Product Owner.
Zunächst schon deshalb, weil die meisten Organisationen denken, es wäre die Rolle des Scrum Masters, die besonders schwierig ist und die ganze Aufmerksamkeit verdient. Daher werden in der Regel auch die Scrum Master zu diversen agilen Trainings geschickt bzw. es werden Scrum Master am externen Markt gesucht, während Product Owner in der Vorbereitungsphase oft unterm Radar bleiben.
Was aber macht die Rolle des Product Owners so problematisch und wie sollte sie angelegt sein, um eine agile Transformation erfolgreich werden zu lassen?
Um das besser zu verstehen, zunächst mal ein paar grundsätzliche Überlegungen zum Rollenverständnis in Scrum und zur Einordnung dieser Rollen in der Organisation. Scrum beschränkt sich auf drei Rollen, den Product Owner, den Scrum Master und das Development Team.
Damit bricht Scrum mit der guten Tradition von Projektorganisationen, ständig neue Rollen zu erfinden. Da gibt es neben den klassischen Projektmanager-, PMO-, und Architektur-Rollen oft noch Implementierungsverantwortliche, Release- und Testmanager, Verantwortliche für gute Laune oder für’s Kaffeekochen, usw. Das mag für Projektorganisationen auch immer irgendwie Sinn ergeben und den Gegebenheiten des Projektes gut angepasst sein.
Dennoch geht Scrum hier den genau entgegengesetzten Weg und beschränkt sich auf genau drei Rollen, unabhängig von allen Projektgegebenheiten.
Dies ist zweifellos ein Perspektiv- oder Paradigmenwechsel. Dieser lässt sich eigentlich auch nur damit erklären – und auch das ist eine häufig gestellte Frage, von der wir gleich sehen werden, dass sie mit der Einführung der Rolle des Product Owner sehr viel zu tun haben wird – dass Scrum im eigentlichen Sinne keine Projektmanagementmethode ist.
Scrum versteht sich eher als eine Implementierungsmethode. Ich verfolge diese Disskussion schon eine ganze Weile und beobachte, dass die Welt da etwas gespalten ist. Einige sehen Scrum also Projektmanagementmethode, andere nicht. Selbst im SAFe Guide liest man an einigen Stellen, das Scrum als eine Projektmanagementmethode gesehen wird und es wird dabei kritisiert, dass Scrum selbst nicht skaliert.
Letzteres stimmt natürlich, aber es liegt wohl eher daran, dass Scrum gar keine Projektmanagementmethode ist, sondern eben nur eine Implementierungsmehtode. Die (skalierten) agilen Projektmanagementmethoden wären dann SAFe, LeSS oder Nexus.
Zunächst mal macht es sie problematisch, dass sie keiner kennt. Diese Rolle gab es früher in Organisationen schlicht nicht.
Das gilt zwar auch, oder vielleicht noch mehr für die Rolle des Scrum Masters, aber diese ist dann doch wieder so neu und so anders und eben durch die neue Methode begründet, dass sie viel leichter akzeptiert wird (was leider aber nicht automatisch bedeutet, dass die Menschen, die diese Rolle übernehmen leicht akzeptiert werden, aber das ist ein ganz anderes Thema).
Richtig problematisch wird die Rolle des Product Owners dadurch, dass viele Organisationen denken, sie wüssten was damit gemeint ist. Für die einen Organisationen steht die Rolle dem klassischen Business Analysten sehr nahe, für andere steht sie dem klassischen Architekten sehr nahe.
Beides ist gleichzeitig falsch und richtig und ich meine damit nicht ein bisschen falsch und ein bisschen richtig, sondern ich meine damit es ist ganz falsch, wenn auch irgendwie verständlich.
Zunächst werfen wir dazu noch einen kurzen Blick auf die drei Rollen in Scrum.
Dabei interessiert uns jetzt mal nicht die Definition der Rollen, sondern ihre Zahl. Es sind drei, es sind nur drei und es sind immer nur drei. Dieser in Organisationen oft wenig beachtete Umstand, hat aber weitreichende Konsequenzen. Denn wenn die Implementierung eines Projektes (nicht das ganze Projekt selbst, den Scrum ist ja „nur“ die Implementierungsmethode) – egal welcher Größe und Komplexität, egal welcher Technologie, egal welcher Organisation und in welchem Setup – sich nur auf drei Rollen stützt, dann ist eines von vornherein klar.
Die Rollen sind derart mit Verantwortung aufgeladen und gleichzeitig mit Aufgaben und Zuständigkeiten bestückt und müssen derart perfekt aufeinander abgestimmt sein, dass man sich hier in der Definition der Rolle und der Positionierung innerhalb der Organisation keinerlei Nachlässigkeiten erlauben kann.
Und schließlich ist die Rolle des Product Owners so exponiert, dass ich aus meiner Erfahrung aus vielen Dutzend Projekten sagen kann, dass ein Product Owner alleine über bis zu 50% der gesamten Team Performance entscheidet, nur durch die Art und Weise wie der die Storys schreibt und wie er sie priorisiert. Ein Product Owner kann mit wenigen (falschen) Handgriffen, ein Projekt komplett zu Fall bringen. Er trägt eine enorme Verantwortung und die lässt sich kaum deligieren.
Kommen wir nun zur Rolle selbst. Und auch hier starten wir mit einem Negativbeispiel, weil ich dieses in inzwischen doch einigen Organisation wiederholt gesehen habe. Und da ich hier nicht an Zufall glaube, sehe ich den Grund dafür in der oben beschriebenen Schwierigkeit von Organisaitonen, die Rolle des Product Owners in Abgrenzung zum Business Analysten oder zum Architekten richtig zu positionieren.
Ich sehe oft zwei Variante:
In der einen Variante wird ein Product Owner bestimmt und er wird von Business Analysten unterstützt, die im Scrum Team mitwirken.
Da Scrum Teams der Definition nach cross-funktional sein sollen wird das gar nicht als Problem erkannt, sondern die Organisation glaubt, dass sie im besten agilen Sinne handelt.
In der zweiten Varianten wird der Business Analyst zum Product Owner gemacht, weil grundsätzlich das Verständnis ist, dass der Product Owner die Aufgabe hat, das Requirement Engineering zu betreiben und dabei auch das Stakeholder Management macht.
Die Business Analysten sind genau das gewöhnt und daher prädestiniert für die diese Rolle.
Beides falsch, wenn auch irgendwie verständlich oder auf den ersten Blick sogar vernünftig oder naheliegend. Aber auf dem zweiten Blick haben beide Varianten fatale Konsequenzen
Es gibt natürlich noch weitere Varianten, in denen z.B. Architekten zu Product Ownern gemacht werden oder die Product Owner Rolle sogar auf mehrere Personen – dann in der Regel wieder Business Analysten als sogenannter „fachlicher Product Owner“ und Architekten als sogenannter „technischer Product Owner“, auf die ich hier nicht alle eingehen möchte. Die ersten beiden Varianten genügen, um die Rolle des Product Owners anschaulich zu erklären. Daraus kann man dann leicht ersehen, warum auch solche weiteren Varianten wie hier kurz gelistet, ebenfalls nicht gut oder sogar völlig abwegig sind.
Um zu verstehen, warum die erste Variante meiner Einschätzung nach nicht gut ist, werfen wir einen Blick auf den Entwicklungsprozess im Allgemeinen selbst. Der sieht doch ganz grob so aus:
Geschäftsprozess (Fachlichkeit) -> Funktionalität (Produkt Feature) -> Technik (implementierte lauffähige Version).
Es wird also zunächst ein Geschäftsprozess beschrieben. Dies geschieht auf der Organisationsebene, sei es im Rahmen eines Demandmanagement Prozesses, oder unmittelbar danach. Wenn die Organisation sich entschieden hat, diesen Geschäftsprozess zu implementieren, dann werden daraus bereits als Teil der Umsetzung die Funktionalität beschrieben. Genau das ist die Aufgabe des Product Owners. Anschließend wird die beschriebene Funktionalität vom Development Team implementiert.
Die Business Analysten sind diejenigen – sofern es sie in einer agilen Organisation überhaupt noch gibt – die die Geschäftsprozesse analysieren und beschreiben. Das für sich genommen kann je nach Thema schon ein ziemlich komplexer Prozess sein. Bei einer großen Bank, die beispielsweise in ihrer mobile App den Geschäftsprozess ApplePay einführen wollte, hatten die Business Analysten einige Monate zu tun, alle Rahmenbedingungen für die Einführung dieses Geschäftsprozesses abzuklopfen:
Damit sind wir schon bei einer zentralen Aufgabe des Product Owners. Er ist das Bindeglied zwischen Projektorganisation mit ihren Stakeholdern und dem Development-Team, die das Produkt implementieren. Er ist der „Eigentümer des Produktes“, nicht des Geschäftsprozesses.
Er beschreibt die funktionalen Anforderungen des Produktes, nicht die fachlichen Aspekte des Geschäftsprozesses. Es kommt hier auf die Unterscheidung von Fachlichkeit und Funktionalität an. Denn die Funktionalität muss nicht nur den Geschäftsprozess implementieren, sondern gleichzeitig auch noch Rücksicht auf viele andere Faktoren nehmen, wie zum Beispiel nicht funktionale Anforderungen, Compliance Anforderungen, Governance, Security, usw.
Als Bindeglied ist der Product Owner eine Art Anwalt des Kunden.
Er vertritt die Interessen der Stakeholder in Bezug auf die gewünschten Geschäftsprozesse, aber gleichzeitig auch die Interessen seiner eigenen Kanzlei, sprich seines eigenen Entwicklungsteams. Er wird also die Funktionalität so setzen, dass der Geschäftsprozess gut implementiert ist, aber die Software wartungsfähig bleibt und überhaupt mit überschaubarem Aufwand erstellt werden kann. Alle, die schon mal diese Rolle hatten, wissen, wie viele Kompromisse man da ständig eingehen muss. In der hier beschriebenen Funktion ist der Product Owner für die Wertmaximierung des Produktes verantworlich. Auch das sollte nicht mit der Wertmaximierung des Geschäftsprozesses verwechselt werden.
Und der Product Owner arbeitet wie gerade gezeigt auf einer ganz anderen Ebene, nämlich auf der Produktebene und nicht auf der Geschäftsprozessebene.
Mit dem Stakeholdermanagement und der Transformation von aller Anforderungen in Funktionalität und er Etablierung einer effektiven Kommunikation zwischen allen Beteiligten haben Product Owner ohnehin schon genug zu tun. Wenn sie sich jetzt auch noch so tief in die Geschäftsprozesse einarbeiten sollen, kommen regelmäßig ihre originären Aufgaben zu kurz. Die Software wird zu Feature-lastig entwickelt und baut viele technische Schulden auf, oder die Teams werden nicht mehr optimal betreut, was zu Lasten der Velocity geht.
Diese Überlegung führt uns zum nächsten zentralen Aspekt der Product Owner Rolle. Kommunikation. Die Rolle der Kommunikation im agilen Prozess habe ich hier als „wechselseitige Einladung in einanders Wirklichkeit“ beschrieben, also als einen essentiellen Transferprozess von Produktvisionen in technisch implementierte Features in kürzester Zeit.
ihm muss es gelingen, seine Produktvision so schnell wie möglich in die Köpfe der Mitglieder seines Entwicklungsteams zu bekommen, damit diese sofort und in kleinen Paketen in kurzen Iterationen komplexeste System entwickeln können.
Er muss also weder ein Fachexperte für die Geschäftsprozesse sein, noch ein Architekt, der die technische Architektur der Anwendung im Detail kennt. Er muss natürlich Zugriff auf beide – und natürlich auch noch auf einige andere – haben und er muss natürlich die funktionale Architektur der Anwendung kennen.
Um all das tun zu können, benötigt er ein paar Rahmenbedingungen. Und diese Rahmenbedingungen entsprechen der Beschreibung der Rolle, wie sie im Scrum Guide aufgeführt sind. Er trägt die alleinige Verantwortung für das Product Backlog, also für den Inhalt und die Reihenfolge der Backlog Items, ganz gleich ob es sich dabei um User-Storys (Features), Enabler-Storys (Technical Depts), Bugs oder andere Aufgaben handelt.
Diese Verantwortung kann er nicht deligieren, aber natürlich kann er sich Hilfe holen wie z.B. bei der Beurteilung von Technical Depts. Vor allem soll das Entwicklungsteam ihn gut beraten können, weshalb die Kommunikation, also der Transfer der Produktvision in das Bewußtsein der Team Mitglieder so wichtig ist. Denn nur wenn sie diese Vision gut verstanden haben, können sie ihn auch kompetent beraten und alle gemeinsam diese in dem Produkt entwickeln und darin zum Leben erwecken.
Was ist die optimale Scrum Sprint Länge? Die überraschende Erkenntnis: 1-wöchige Sprints sind effektiver! Lese hier warum.
Scrum als Risikomanagement: Wie können agile Organisationen einen Scrum Prozess organisieren, ohne dabei die meiste Zeit im Dunkeln zu tappen?
Wie du die Scrum Velocity berechnen und diese so darstellen kannst, sodass sich ein echter Trend abzeichnet von dem ihr eine Prognose ableiten könnt. + kostenloses Excel Template
Für Scaled Agile Organisationen kann es frustriererend sein, wenn Projektmanagement Tools ihre Prozesse nicht unterstützen.
Daher haben wir scagile als eine App entwickelt, die aktiv agile Best-Practices fördert und mit der ein Value Flow über die gesamte Organisation hinweg etabliert wird.
