Rolle des Product Owners im SCRUM Team

[maki]

Hi,

mir ist aufgefallen, dass die Rolle des Product Owners in SCRUM Teams im allgemeinen gerne mal als „Boss“ Rolle missbraucht wird.

Habe das in der Vergangenheit gesehen, bei einigen Firmen, oft bei solchen die sich mit agilem Vorgehen schwer tun, speziell wenn es darum geht dass da kein Platz ist für einen „Boss“, sondern es darum geht, dass das Team Entscheidungen trifft, falls das nicht klappt kann schon mal der Team Lead entscheiden.

Wir haben jetzt eine PO, die „leitet“ alle meetings (Daily, Refinement, etc. pp.), trifft technische Entscheidungen (ohne technischen Hintergrund), eröffnet Meetings, schliesst diese, lässt kaum jemanden zu Wort kommen, da wir sogar eine „zertifizierte SCRUM Masterin“ (find ich ehrlich gesagt auch komisch, aber naja) haben, langweilt ich diese sehr, die Stimmung im allgemeinen ist nicht gut und man fühlt sich nicht wirklich „sicher“, könnte ja jederzeit vom Boss unterbrochen bzw. zurechtgewiesen werden.

Andere Teams hier haben sogar Projektmanager (hilfe), das erinnert mich stark an das gebaren unserer PO, die meint nämlich auch die wäre Projektmanager…

Klar hab ich mir das wohl selber ausgesucht (Tipp: während dem Vorstellungsgespräch sollte man doch fragen ob man da denn Agil entwickelt, ist nicht gegeben 2021), aber darum geht es mir hier nicht.

POs mag ich am liebsten wenn sie sich um das Backlog kümmern und um das Produkt an sich, also so wie SCRUM das vorschreibt.

Wie ist denn eure Erfahrung mit diesen Rollen?

[CyborgBeta]

Ich möchte meinen Senf als erstes dazugeben. Obwohl ich von den an dem Projekt beteiligten Akteuren wenig Ahnung habe, kann nicht jeder ein @Landei sein. Soll bedeuten, ist die Projektstimmung erst einmal „vergiftet“, hilft manchmal nur die Flucht nach vorn antreten. Es kommt auf eure Kommunikationswegehierarchie an, nicht immer ist eine horizontale Hierarchie und kurze Wege von Vorteil… sprich: Sprich mit dem oder der betreffenden Person über mögliche Kompetenzüberschreitungen, also mache deinen Standpunkt klar und zeige die Grenzen auf. Weiterhin alles Gute.

[Firephoenix]

Eigene Erfahrung: Vom „Boss“ aus deiner Beschreibung bis zum „Muster-PO“, die sich um die Stakeholder gekümmert und aktiv Backlog und Produktvision verwaltet hat, war fast alles dabei. Besser geht es meistens, wie gut das klappt hängt von der Firmenkultur und dem Team ab.

Die Rolle PO = Projektmanager kenne ich aus dem agilen Cargo Cult. Das kann man verbessern. Das Team und die Firma müssen aber mitspielen und Veränderung wollen. Zu akzeptieren, dass man eben einen Projektleiter hat und keinen klassischen PO ist auch eine Option. Dann sollte man sich aber ehrlicherweise gleich mit von dem Attribut „agil“ verabschieden.

Das ein Projektleiter/Manager ohne technischen Hintergrund technische Entscheidungen trifft ist auch ein Antipattern, für mich sogar das schlimmere. Wenn noch dazu kommt, dass dann Entwickler für falsche Entscheidungen den Kopf hinhalten dürfen … no comment.

[maki]

@Firephoenix

Eigene Erfahrung: Vom „Boss“ aus deiner Beschreibung bis zum „Muster-PO“, die sich um die Stakeholder gekümmert und aktiv Backlog und Produktvision verwaltet hat, war fast alles dabei. Besser geht es meistens, wie gut das klappt hängt von der Firmenkultur und dem Team ab.

Muss ehrlich sagen dass ich das nur vom hörensagen kannte bzw. in Vorstellungsgesprächen mitbekommen habe bis jetzt und da war das ein KO Kriterium, wenn die natürlich nix sagen und ich nicht frage…

@Firephoenix

Die Rolle PO = Projektmanager kenne ich aus dem agilen Cargo Cult.

Hui, ist das erste mal dass ich diesen Begriff höre, aber der passt zu 100%.

In der letzten Firma war alles agil, bis hoch zur Geschäftsleitung bzw. den Gründern, diese Firma macht SW für agile SW Teams, da bin ich wohl dazu Übergegangen das als normal zu unterstellen.

@Firephoenix

Das Team und die Firma müssen aber mitspielen und Veränderung wollen. Zu akzeptieren, dass man eben einen Projektleiter hat und keinen klassischen PO ist auch eine Option. Dann sollte man sich aber ehrlicherweise gleich mit von dem Attribut „agil“ verabschieden.

Sehe ich ganz genauso.

Im Moment streitet man sich in der neuen Firma, ob Releasezyklen auf 1 Monat von 3 Monaten verkürzt werden sollen, und da gibt es extremen Gegenwind

@Firephoenix

Das ein Projektleiter/Manager ohne technischen Hintergrund technische Entscheidungen trifft ist auch ein Antipattern, für mich sogar das schlimmere. Wenn noch dazu kommt, dass dann Entwickler für falsche Entscheidungen den Kopf hinhalten dürfen … no comment.

Ja, mittlerweile bin ich der Ansicht, dass es nicht ein Problem eines falsch implementierten/angewendeten agilen Prozesses, sondern die Teamarbeit an sich die hier nicht geschätzt bzw. gefördert wird.

Das ist für mich eine grosse kulturelle Umstellung, von „celebrate mistakes“, „play as a team“ etc. pp. umschwenken auf „the boss is always right“.

@Firephoenix

Das ein Projektleiter/Manager ohne technischen Hintergrund technische Entscheidungen trifft ist auch ein Antipattern, für mich sogar das schlimmere. Wenn noch dazu kommt, dass dann Entwickler für falsche Entscheidungen den Kopf hinhalten dürfen … no comment.

Das kommt dabei raus wenn man in einem „Haifischbecken“ schwimmen geht, Fehler sind schwächen und Manager haben sowas nicht, der Umganston ist eher rauh von den PO oder Projektmanagern.
„ask for permission first“ usw., also komplett anti-agil.
Dazu kommt dass hier sehr viele politische Spielchen gespielt werden.
Für SW Entwickler ist die Umgebung schlecht geeignet, da für alle Tools die man braucht Anträge gestellt werden müssen, diese oft über eine Woche bearbeitet werden, obwohl das Ergebniss nur „genehmigt“ sein kann, oder sol ich ohne JDK entwickeln?
„Security #1“, „zero trust“ und so

Ich bin seit der zweiten Woche hier wieder auf der Suche, ist zwar schade, aber ich habe gelernt dass man nicht unterstellen darf das Agil normal und üblich ist, gibt anscheinend einige grosse Unternehmen die in der 90er Jahren festhängen.

[darekkay]

Dafür ist eigentlich die Retrospektive da. Man benennt ein Problem, und wenn die Mehrheit das ebenfalls als Problem sieht, wird daran geabeitet. So die Theorie und in einem funktionierenden Scrum-Team auch Praxis. Da aber euer PO seine Rolle nicht zu verstehen scheint, könnte das schwieriger werden.

Leider muss heute jedes Projekt agil sein, egal ob es das auch faktisch ist. Waterfall-Scrum ist oft anzutreffen: das Projekt ist vertraglich ein klares Wasserfallprojekt, aber man führt trotzdem Dailies, Retros, Reviews, Scrum Master und Product Owner ein, weil niemand in dieser Zeit zugeben darf, dass sie kein Scrum machen.

Ich habe Glück, denn in meinem Projekt steht der Kunde hinter dem agilen Konzept. Es läuft nicht alles 100% nach Lehrbuch, aber ich bin mit dem aktuellen Prozess sehr glücklich. Sowohl die Scrummasterin als auch die PO verstehen ihre Rollen und überlassen dem Team so gut wie es geht die Selbstorganisation. Es ist aber etwas, das wir uns in den letzten 4.5 Jahren erarbeitet haben (und das trotz großer Fluktuation im Team).

[maki]

@darekkay

Dafür ist eigentlich die Retrospektive da. Man benennt ein Problem, und wenn die Mehrheit das ebenfalls als Problem sieht, wird daran geabeitet. So die Theorie und in einem funktionierenden Scrum-Team auch Praxis. Da aber euer PO seine Rolle nicht zu verstehen scheint, könnte das schwieriger werden.

Ja, das ist ja das Problem mit der „Pseudo Agilität“, dass man zwar „die Bewegungen“ mitmacht aber nix von der eigentlichen Idee.

„ask for permission first“, dazu kommt die Tatsache dass hier alles, aber wirklich alles über Formulare gemacht werden muss, hab schon ein Formular ausgefüllt um ein Formular ausfüllen zu dürfen (I need to create a ticket to get access to A, to create that ticket I need access to the ticket system which requires me to fill out a form in a different system…).
Dazu kommt das Projektleiter sozusagen in er Firmenstruktur vorgeschrieben sind.
IMO ist da Hopfen & Malz verloren, ist aber egal, muss mir selber ja nur was suchen was besser passt.

@darekkay

Leider muss heute jedes Projekt agil sein, egal ob es das auch faktisch ist. Waterfall-Scrum ist oft anzutreffen: das Projekt ist vertraglich ein klares Wasserfallprojekt, aber man führt trotzdem Dailies, Retros, Reviews, Scrum Master und Product Owner ein, weil niemand in dieser Zeit zugeben darf, dass sie kein Scrum machen.

Hehe, sehe ich hier auch so.
Externe „SCRUM Master“, zertifiziert etc. pp.

Sowas gab es in der letzten Firma nicht, da wurde nur agil gearbeitet, die Streitpunkte waren SCRUM vs Kanban für ein Team das neben Features auch Operative Aufgaben hatte.
Hat man gelöst in dem man mal Kanban für die operativen Sachen nahm (Bugs/operational related tasks).

Die Sache mit der Selbstorganisation führt ja dazu, dass das Team an sich Verantwortung trägt und hinter den Entscheidungen steht.
Hier denke ich mir halt „das hab ich ja gleich gesagt dass das nicht geht“ und damit ist für mich dass dann erledigt.