Direkt zum Hauptbereich

Product Owner: Highlander oder Teams?


Aktuell gibt es im Web eine Diskussion über den Product Owner als Highlander oder als Team.

Um so mehr ich da drüber nachdenke, desto mehr frag' ich mich ob wir die Rolle des Product Owners im Team bisher richtig verstanden haben.

Fast unstrittig scheint zu sein, dass der PO ein Team haben kann, welches ihm zuarbeitet. Bei größeren Projekten kann er ja unmöglich alles Wissen vereinen und neben dem technischen Verständnis auch noch die BusinessAnalyse, das RequirementsEngineering usw. alleine machen. Also stellen wir ihm ein Team zur Seite, welches ihn unterstützt. Und hier ist nun die Frage warum dieses Team einen "Vorsteher" mit der Verantwortung haben muss und nicht selbstorganisiert auch die Verantwortung teilen kann.



Und hier beginn ich mir gerade so meine Gedanken zu machen:

Ist es denn im Sinn von Scrum, wenn ich dem Product Owner ein Team zur Seite stelle, welches ihn bei der Businessanalyse, dem Requirementsengineering unterstützt und fachliches Wissen bereitstellt?

Meine Antwort ist ein klares Ja und Nein:

Nein: Es kann nicht im Sinne eines agilen Modells sein die Entwickler weiter vom Kunden und Anwender fern zu halten und das Wissen durch ein "externes" Team zu filtern und zu bewerten.

Ja: Natürlich muss der Product Owner seinen Job nicht alleine machen! Er gehört ja bereits zu einem Team: dem Scrum Team. Hier sind auch die Personen zu finden, welche zusammen mit dem Kunden und Anwender das benötigte Wissen und die Fähigkeiten haben um die Anforderungen aufnehmen zu können. Dadurch sitzen die Entwickler direkt an der Quelle und müssen nicht noch mal die Anforderungen von dem PO-Team ermitteln. Des weiteren entwickeln sie gleich eine gemeinsame Vision die bei der Umsetzung des richtigen Features hilft.

Wenn ich nun die Product Owner Verantwortung an das Team übergebe, so entscheiden die Entwickler über die Reihenfolge der Umsetzung und die eingebauten Features? Gerade in jungen Teams seh' ich da schon goldene Tellerränder ohne Teller. Was nicht heißen soll, dass der PO das alleine tun muss nur die endgültige Entscheidung liegt bei ihm.

Ich denke wenn wir den Product Owner oder sein Team weiterhin als Kombination aus altem Projektmanager (Reihenfolge) und Businessanalyst / Requirementsengineer (Was) sehen, haben wir mit dem Einsatz noch nicht viel gewonnen, bis auf die iterative Auslieferung von Meilensteinen.

Kommentare

Beliebte Posts aus diesem Blog

Eine Retro im Kreis

Für die letzte Retro habe ich die Tische und Stühle alle beseite gestellt um dann mit Klebeband (Malercrep) drei unterschiedlich große Kreise um einen Mittelpunkt zu kleben. Der innerste Ring war groß genug, dass das gesamte Team da drin Platz finden konnte.

Für die erste Phase der Retro habe ich Kärtchen mit den Zahlen 50, 40, 30, 20 in den Ringen verteilt. Die 50 in der Mitte und dann absteigend nach außen. Um so eine Zielscheibe anzudeuten.

Speed Temenos auf dem AgileDay der JAX

Letzte Woche hatte ich die Gelegenheit auf dem AgileDay der JAX zu sein. Neben Vorträgen am Vormittag mit Beiträgen zu Retrospektiven agile in Konzernen sowie einer spezifischen Implementierung in einem Unternehmen stand nach der Mittagspause ein Speed Temenos mit Olaf Lewitz und Christine Neidhardt auf dem Programm. Zur Unterstützung hatten sie sich Unterstützung über die Softwerkskammer organisiert, so dass die Anwesenden von insgesamt 20 Facilitatoren betreut wurden.

Bei Temenos handelt es sich um einen "geschützten Raum" in dem Menschen Offenheit und Vertrauen erleben können. Das Speed Temenos mit seinen 3 Phasen, in welchen es um die Persönliche (Berufliche) Vergangenheit, den Ist-Zustand und die Vision für die Zukunft geht hilft über Geschichten erzählen, sich selbst zu reflektieren und Gemeinsamkeiten in der Gruppe zu entdecken. Details sind auf http://trusttemenos.de/ viel besser erklärt als ich es hier kann.

Ich hatte Temenos mit Olaf bereits auf der Play4Agile 201…

Der Wasserfall ist immer noch vorherrschend in der Softwareentwicklung

In den letzten Jahren sind viele "neue" Bewegungen auf der Bildfläche des Mainstream-Bewusstseins der Softwareentwicklung erschienen. Und viele aktuelle Studien berichten, dass die Agilität den Wasserfall abgelöst hat. In allen Softwareunternehmen und viele der Entwickler die ich treffe reden zumindest viel über Agilität.

Wenn aber mal einen Schritt zurück macht sieht das (ideal) Bild eher so aus:

Die neue Lösung wird mit Design Thinking gefunden und definiert. In der Entwicklung ist dann eher die Rede von agile (meist Scrum) und selten SoftwareCraftsmanship. Von der Betriebsseite heißt es nun DevOps. Aber dazwischen gibt es immer noch Brüche und es existiert keine Ganzheitlichkeit.

Jahrzehnte lang haben wir in der Softwareentwicklung geglaubt und es so auch allen Kunden beigebracht, dass die "Cost of Change Curve" gilt und daher der Wasserfall als Vorgehen perfekt ist.
(Was nun was bedingt, lass ich mal dahingestellt)

Dadurch haben sich natürlich auch die Struktur…