Scrum gibt uns nur ein sehr grobes Framework an die Hand. Es liegt an uns, es mit Leben zu füllen. Dabei haben wir viele Freiheiten, womit auch viele Gefahren verbunden sind (frei nach dem Prinzip »mit großer Macht kommt auch große Verantwortung«). Wir müssen nicht die Welt oder die hübsche Blondine vor dem Bösewicht retten, aber wir müssen einen Weg finden, der für unser Team funktioniert aber die Agilen Prinzipien nicht verletzt. Ist das schwierig?
Kurze Antwort: ja. Ich möchte hier jedoch nicht jeden einzelnen Aspekt beleuchten, weil das mit Sicherheit den Rahmen sprengen würde, aber ich würde gern ein paar Gedanken zur Rolle des Product Owners mit Ihnen teilen, weil gerade in den Rollen eine ganze Bandbreite an Optionen vor uns liegen, die sich alle ganz wunderbar mit Scrum und der Agilen Welt vereinbaren lassen, aber zu einem gänzlich anderen Vorgehen führen.
Wenn wir die (reichlich vorhandene) Literatur zur Rolle des POs bemühen, dann lässt es sich ganz schlicht zusammenfassen: der Product Owner entscheidet das Was, die Entwicklermannschaft entscheidet das Wie.
Ganz so möchte ich das aber nicht stehen lassen. Zum einen ist mir das zu einfach, zum anderen widerspricht es meinem Verständnis von Kollaboration, denn im Schluss bedeutet diese Vereinfachung nichts Anderes als, dass der PO dem Team einen Topf von Aufgaben in Form eines priorisierten Backlogs übergibt, und dann erst wieder bei der Abnahme im Review involviert ist, ebenso wie das Team bei der Erstellung des Aufgabentopfes die Klappe zu halten hat. Ist das wirklich das was wir wollen?
Auch hier kann ich eine ganz einfache Antwort geben: ganz bestimmt nicht. Wer tatsächlich so vorgehen möchte, wird sehr schnell Probleme bekommen. Spätestens wenn das Team den PO im Planning mit der Aussage konfrontiert, dass es Abhängigkeiten gibt, die sich bei dieser Priorisierung nicht auflösen lassen, stehen wir vor einem Problem.
Am anderen Ende der Skala finden wir das Extrem, dass alle Entscheidungen gemeinsam getroffen werden, was sowohl die Erstellung der Anforderungen als auch deren Priorisierung betrifft. Was wäre aber in diesem Fall die Aufgabe des Product Owners. Beim ersten Hinhören klingt es so, als könne das Team bei einem solchen Vorgehen auch ganz wunderbar ohne PO leben.
Kann es selbstverständlich nicht. Auch wenn wir alles im Team entscheiden und der PO das Team schon zu einem sehr frühen Zeitpunkt in der Entstehung einer Anforderung mit ins Boot holt, so ist er dennoch immer der Vordenker. Wenn Sie einige der anderen Artikel gelesen haben, die ich geschrieben habe, dann wissen Sie, dass ich ein großer Verfechter des Ansatzes bin, eine Entwicklermannschaft so früh wie möglich in den Konzeptionsprozess einzubinden, weil ich damit viele Vorteile verbinde. Das bedeutet jedoch nicht, dass alle jede Idee und jedes Feature vom ersten Moment an gemeinsam entwickeln müssen. Es ist nicht die Aufgabe des Entwicklers, mit den Kunden zu sprechen. Es ist auch nicht Aufgabe der Entwickler, mit den Kollegen aus dem Marketing zu sprechen, um eine Kommunikationsstrategie für ein neu entwickeltes Feature zu erarbeiten. Es ist Aufgabe des PO, die Stimmen und Anforderungen aller zu sammeln, abzuwägen und zu bewerten. Diese Sache sehe ich nicht bei der Entwicklermannschaft sondern konkret in der Rolle des Product Owners.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
In meinem Verständnis sollten wir bei der Definition der Rollen in einem Team über Schwerpunkte sprechen ohne dabei klare Grenzen zu vernachlässigen. Die Entscheidung, wie eine Sache umgesetzt wird, bleibt in Entwicklerhand. Der PO hat im Code nichts zu suchen, was jedoch nicht bedeutet, dass er sich dafür nicht interessieren darf. Ein Product Owner mit technischem Hintergrund kann sich sehr wohl für Details der Umsetzung interessieren und darf (in meinem Verständnis) auch Vorschläge machen. Die Entscheidung trifft jedoch nicht er. In diesem Fall wäre der Scrum Master gefordert, auf die Einhaltung dieser Entscheidungsgrenzen zu achten.
Andersherum liegt die letzte Priorisierungsentscheidung beim Product Owner. Schließlich ist er nach außen verantwortlich. Das bedeutet jedoch nicht, dass er sich hierbei nicht mit dem Team abstimmen sollte. Ganz im Gegenteil: es wäre sogar ausgesprochen dumm, sich bei der Priorisierung nicht mit den Entwicklern abzustimmen. Erst beim gemeinsamen Blick auf das Backlog werden Abhängigkeiten deutlich, die der Product Owner unter Umständen nicht kennen kann. Ihm fehlt in aller Regel der tiefe Einblick in die technischen Zusammenhänge, der erst durch den Input der Entwickler Einfluss auf die Priorisierung hat.
Diese Dinge sind technische Aspekte unseres Vorgehens, die selbstverständlich unsere Arbeit beeinflussen aber nur eine Facette meiner Überlegungen darstellen. Eine andere Seite möchte ich ganz grob mit dem Wort »Commitment« überschreiben.
Selbstverständlich ist uns dieser Begriff schon oft begegnet, wenn wir über Sprintplanning sprechen, ich möchte es an dieser Stelle jedoch etwas weiter fassen. Ein Team kann nur voll und ganz hinter einer Sache stehen, wenn es involviert ist. Wie das genau aussehen kann, ist noch zu klären, aber die Frage muss gestattet sein: ist ein Team involviert, wenn es zum Sprintbeginn oder kurz davor ein Backlog präsentiert bekommt, an deren Erstellung es nicht mitgewirkt hat? Der Gedanke fällt mir recht schwer. Als Entwickler mache ich in diesem Fall das, was man mir sagt, aber ist das nicht genau das, was wir nicht wollen?
Was ist denn dann ein »gutes« Vorgehen, und wie definiert sich dabei die Rolle des Product Owners? Nähern wir uns diesem Problem doch einmal von der anderen Seite, indem wir uns fragen, was wir eigentlich erreichen wollen: wir wollen früh beim Kunden sein, um in einen Regelkreis zu kommen, den ich entweder Plan-Do-Check-Act oder Build-Measure-Learn oder wie auch immer nennen kann. Im Grunde ist alles gleich. Wir möchten Dinge tun, lernen, dann das Gelernte bei unserem weiteren Vorgehen berücksichtigen. In meinem Bild ist der Product Owner derjenige, der diesen Regelkreis lebt, das Team hilft ihm dabei. Damit ist der PO derjenige, der unser Produkt vorantreibt. Wenn wir bei Plan-Do-Check-Act bleiben, ist er an allen vier Stationen der Koordinator, aber an keiner dieser vier Stationen ist er allein. Das ist für mich der entscheidende Punkt. Ein Product Owner ist Vordenker, Koordinator, Kommunikator und auch der Umsetzende. In all diesen Aspekten seiner Rolle wird er jedoch von allen anderen (mal mehr mal weniger stark) unterstützt.
Jetzt werden Sie möglicherweise fragen, inwiefern der PO der Umsetzende ist, schließlich ist es Aufgabe der Entwicklermannschaft, den Code zu schreiben. Dem müsste ich jedoch entgegnen, dass ich diesen Begriff hier etwas weiter fassen möchte, indem ich unter Umsetzung eben nicht nur Code verstehe sondern auch Roadmap und Backlog.
Jetzt stehen wir aber wieder vor so einem schwammigen Etwas, wenn ich sage, dass der PO den Regelkreis lebt und dabei von allen unterstützt wird. Ich könnte auch sagen, dass der Product Owner Dreh- und Angelpunkt des Teams ist, was aber ebenso schwammig ist.
Eine andere Formulierung ist ebenso richtig: Der PO ist kein Einzelkämpfer. Das darf er nicht sein, und das kann er auch nicht sein. Allein wird er niemals in der Lage sein, das Backlog so zu priorisieren, dass es nicht zu Konflikten technischer Natur kommt. Darüber hinaus wird das Team niemals das Produkt als »Seins« annehmen, wenn es sich nicht aktiv an dessen Entstehung beteiligen kann. Das geht weit über die Erstellung des Codes hinaus.
Bitte verstehen Sie mich jetzt nicht so, dass ich den Product Owner in seinen Rechten beschneiden will. Ich möchte nur dafür sensibiliseren, dass der Product Owner keinen Aspekt seiner Aufgaben allein besser bewältigen kann als mit Unterstützung.
Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.
