Gleichzeitig Projektleiter und Product Owner?
Ja oder nein – beides ist okay
Die Frage, ob ein Projektleiter auch als Product Owner agieren könnte, lässt sich kurz und knapp beantwortet „ja" oder „nein" beantworten. Negativ entsprechend dem Framework Scrum, da dies keinen Projektleiter vorsieht. Positiv aus Sicht eines Projektleiters, der damit verbunden ggf. eine besondere Wichtigkeit im Anforderungsmanagement sieht (und sich für den Erfolg seines Projektes einsetzt anstatt an Formalien zu denken, wie z.B. Rollen, RACI, etc.).
Allerdings wird mit der signalisierten Bereitschaft bereits eine Annahme getroffen, die es zu hinterfragen gilt. In die gleiche Richtig entwickelte sich die Diskussion beim Stammtisch. Fragen kamen auf, was verspricht sich der Auftraggeber (d.h. welches Ziel soll erreicht werden)? Oder in wie fern besteht ein gleiches Verständnis bzgl. Rollen und Verantwortlichkeiten? Somit lässt sich die Frage eigentlich erst beantworten, wenn die Rahmenbedingungen geklärt sind.
Pragmatisches Vorgehen und Vorsicht vor falschen Vorstellungen
Agile Methoden in das phasenweise Vorgehen zu integrieren können z.B. mittels Daily Stand-Up, Kanban-Board, Pilot-Modell vor der Umsetzung erstellen oder jeweils die nächste Phase konkret planen, etc. sein. Wer bereits positive Erfahrungen gesammelt hat, wird in der Reflektion ggf. erkennen, dass ein pragmatisches Vorgehen zur täglichen Arbeit gehört, in dem die Vorteile beider Vorgehensweisen zum Vorteil des eigenen Projektes für die entsprechende Zielerreichung eingesetzt werden können.
Unabhängig davon sollte agiles Arbeiten nicht mit „totaler" Flexibilität verwechselt werden. Ebenso wenig bedeutet Scrum, dass nicht dokumentiert werden muss (nebenbei: dokumentiert wird, wenn gefordert z.B. nach ISO oder wenn es einen Mehrwert gibt z.B. weniger Aufwand im Produkt). Zudem sollte agiles Arbeiten nicht pauschal mit Kosteneinsparung gleichgesetzt werden, da die Basis für ein Vergleich nicht gegeben ist. Und bzgl. der „totalen" Transparenz wäre u.a. die Mitarbeiterzufriedenheit ein Indikator für mögliche Grenzen.
Zielsetzung klären
Im Bezug auf die eingehende Frage können unterschiedliche Annahmen betrachtet werden. Exemplarisch dazu: Wenn die Anforderungen an das Produkt unklar sind, dann könnte mittels Iterationen diese erarbeitet bzw. konkretisiert werden. Dabei wäre zu empfehlen, neben dem Auftraggeber auch die Kunden/Nutzer mit einzubeziehen. Aus den Ergebnissen, die auf Zuspruch stoßen, wird je Iteration die Anforderungen für das Produkt immer konkreter entwickelt. Von Vorteil ist, wenn dem Auftraggeber klar ist, dass sein Engagement Indikator für die Wichtigkeit ist.
Mit Blick auf das Rollenverständnis: Wenn ein*e Verantwortliche*r für das Produkt ein Projekt leitet, dann kann davon ausgegangen werden, dass ihr*ihm die Linientätigkeiten bekannt sind. Dann stellt sich die Frage, in wie fern Know-How im Bezug auf Projektmanagement vorhanden ist oder aufgebaut werden sollte. Andersherum stellt sich die Frage, welches Know-How und welche Aufgaben muss ein*e Projektleiter*In erfüllen, wenn davon ausgegangen wird, dass die Aufgabe mit der Einführung des Produktes endet. D.h. unabhängig der Konstellation ist die Zielsetzung zu klären, bevor die Frage jeweils individuell beantwortet werden kann.
When you subscribe to the blog, we will send you an e-mail when there are new updates on the site so you wouldn't miss them.
Comments 2
Ich bin da ganz bei Dir. Mit einem anderen Verständnis und anderem Blickwinkel sowie weiteren Kenntnissen kann ein guter Projektmanager* auch ein guter Product Owner sein et vice versa.
Als Agile Coach sehe ich das folgendermaßen:
Es kommt auf die Rahmenbedingngen an. Welcher Vertrag liegt vor? Ist der Kunden bereit, schnell über Änderungen für ein besseres Produkt zu entscheiden? Kann der Kunde vor Ort sein?
Wenn die Kunden nicht vor Ort sein wollen oder können, dann kann der Projektleiter ein Proxy-PO zum Kunden darstellen. Stehen Kunden zur Verfügng, sollten sie einen PO stellen. Das geht natürlich nur bei einer gegenseitig wertschätzenden Atmosphäre.
Ziel ist es, schnell Entscheidungen für ein besser Produkt zu treffen und sich nicht zu eng an Verträge zu halten. Wenn es gegenseitiges Misstrauen gibt, dann funktionieren agile Vorgehensweisen eh nicht. Dann sollte sich das Projekt aber auch von den Begriffen aus Scrum verabschieden, denn dann ist es lediglich Zombie-Scrum. Es geht, aber es ist nur ein Feigenblatt und dahinter ein klassisches Projekt.