Wie besetze ich die Rolle des Product Owners

Prinzipiell ist es nie leicht die Rollen in Scrum adäquat zu besetzen. Der Product Owner (PO) ist dabei keine Ausnahme. An dieser Stelle kann ich deshalb keine generellen Empfehlung aussprechen, einfach weil dies meines Erachtens nicht möglich ist. Stattdessen beschreibe ich den Weg, den wir in der Firma heco mit Erfolg gegangen sind.

Einer unserer Administratoren in der IT sprach mich darauf an, dass er mit seinen Aufgaben zum Teil unterfordert ist und sich zum Teil auch noch mehr einbringen wolle. Beim Reflektieren darüber stachen für mich 5 wesentliche Eigenschaften hervor:

  • In seiner aktuellen Aufgabe hatte unser Admin sehr engen und guten Kontakt zu allen Mitarbeitern, die das Produkt (hauseigenes ERP-System) einsetzen
  • Sein Verständnis für Geschäftsprozesse war stark ausgeprägt, was auch seine akademische Karriere (Wirtschaftsgymnasium, DHBW Studium) belegte
  • Seine IT-Kenntnisse machten die Kommunikation mit dem Entwickler Team einfacher
  • Er betreute bereits das Produkt auf technisch administrativer Ebene
  • Er war motiviert und wollte das Produkt aktiv mitgestalten

Klar war aber, dass ihm das fachliche Know How und deshalb auch die konkrete Produktvision fehlen würde. Deshalb waren die ersten zwei Schritte ihn direkt zu der Person zu setzen, die das Produkt bis ins kleinste Detail kannte: Unseren Geschäftsführer. Um den Einlernungsprozess zu beschleunigen, war die erste Aufgabe eine vollständige Dokumentation über alle Schnittstellen zu schreiben – sowohl fachlich (das WAS) als auch technisch (das WIE).

In der anschließenden Retrospektive zeigte sich, dass damit der Lernprozess nicht schnell genug voran kam. Deshalb übertrugen wir ihm die Aufgabe alle User Stories fortan selbst zu erfassen. Wir wichen also von den Empfehlungen der Standardliteratur ab, dass die Entwickler die User Stories schreiben sollen. Für mich eine der besten Entscheidungen überhaupt. Immer wenn er nicht in der Lage war die User Story zu erfassen, egal ob zu formulieren oder gemäß dem Business Value zu priorisieren, musste er mit unserem GF darüber sprechen. Zur Gänze hab ich ihn immer zusammen mit den Fachexperten die zugehörigen Informationen im Unternehmens-Wiki festhalten lassen, also z.B. die erarbeitete Domänen-Sprache (vgl. Ubiquitous Language) oder die Bedienungsanleitung. Konsequenterweise war er auch an allen Meetings anwesend. Dass Informieren der Mitarbeiter in Form von Trainings, Schulungen oder E-Mails vervollständigte die Botschaft: Er ist der PO, an den sich die Belegschaft wenden muss.

Die ersten 4 Monate agierte er als sogenannte Proxy Product Owner, der dem eigentlichen PO (in unserem Falle dem Geschäftsführer) versuchte möglichst viel Arbeit abzunehmen, v.a. wenn dieser nicht die nötige Zeit für die Ausübung seiner Rolle hatte. Der Anlernphase folgte dann das Gespräch mit unserem GF, in welchem er seine PO Position übergab. Das bedeutete in erster Linie: Benötigt das Entwickler Team sofort eine Antwort auf eine Frage, dann hat der neue PO die entsprechende Kompetenz, eine etwaig endgültige Entscheidung zu treffen. Diesen Aspekt möchte ich ganz klar hervorheben, weil er nicht unterschätzt werden darf! Zuvor hatten wir bereits eine 100%ige Verfügbarkeit des PO für das komplette Scrum Team erreicht. Diese beiden Eigenschaften zusammen lieferten einen unglaublichen Impuls für die Entwicklung.

Ein Beispiel hierfür: In der Vergangenheit trauten sich die Kollegen aus den Niederlassungen nicht direkt an unseren Geschäftsführer mit Verbesserungsvorschlägen oder Fehlermeldungen heran. Oftmals wählten sie einen Umweg über mich, jedoch verwies ich immer auf den GF als Product Owner, da ich nicht priorisieren konnte bzw. wollte. Das Problem war mir bereits früher aufgefallen, doch fand ich nie eine zufriedenstellende Lösung. Inzwischen ist eine äußert produktive Feedback Kultur entstanden, bei der die Belegschaft die Umsetzung ihrer Wünsche logischerweise sehr positiv aufnimmt.

Selbstverständlich machte unser PO parallel zur Produktschulung regelmäßig Scrum Schulungen (Inhouse), las Bücher (Empfehlung hier), ging zu Scrum Stammtischen oder machte Webinare. Alternativ kann auch ein externer Berater herangezogen werden, mit dem die ersten Schritte gemeinsam gegangen werden.

 

Mich würde interessieren, wer unter den Lesern mit der unternehmenseigenen Besetzung des PO zufrieden ist. Vor allem in Hinblick auf Verfügbarkeit fürs Team!

Mit Tag(s) versehen:

4 thoughts on “Wie besetze ich die Rolle des Product Owners

  1. Sebastian 26. April 2014 um 7:39 Reply

    Ich hab mich daran gewöhnt das Product Owner, aus der oberen Etage kommen, also Bussines Maker sind. Ich habe die Rolle des PO auch so verstanden das er am Ende entscheiden muss , gehe ich das Risiko ein, kaufe ich das so In-House jetzt so ein oder nicht. Jemanden aus der Arbeitsebene zum PO zu ernennen ist generell wohl eine schlechte Idee. (Zumindest nach meiner Erfahrung, dem entgegen steht das man für seine Aufgabe eigentlich unterfordert sein muss um sie wirklich maximal auszufüllen(das Peter Prinzip))

    PS: Das die User Stories nicht von den Entwicklern kommen, finde ich auch genial. Leider haben nur die wenigsten Firmen die Ressource dafür.

    Gefällt mir

    • Uli Armbruster 26. April 2014 um 13:16 Reply

      Hey Sebastian,
      deshalb benötigt ein PO, der aus der „unteren Etage“ kommt auch die klare Kompetenz für die Entscheidungen. Das hatten wir in unserem Fall so mit der Geschäftsleitung vereinbart. Spräche aus deiner Sicht dann noch etwas dagegen?

      Das Problem, wenn Developer die User Stories schreiben müssen, hebe ich mir für einen separaten Blogeintrag auf.

      Gefällt mir

  2. Sebastian 27. April 2014 um 15:58 Reply

    Hey Uli,

    Grundsätzlich gibt es keinen generellen Grund warum das nicht gehen sollte. Ich würde aber darauf Wert legen das derjenige über die Credibility innerhalb des Projekt-Teams verfügt, also jemand der sich verdient gemacht hat und vom Team insgesamt anerkannt wird und last-but-not-least über praktische Erfahrung mit diesem Vorgehensmodell verfügt.(Aus meiner Sicht ist Credibility ein unterschätzter Faktor. Einigen im Team traut man mehr zu und anderen weniger.)

    Bemerkenswert finde ich, das ihr der Geschäftsleitung abringen konntet, segnifikante Risiko-Entscheidungen einem PO zu übertragen der nicht aus der Geschäftsführung bzw. dem mittleren Management kommt. Das habe ich bis heute für unmöglich gehalten :)

    Gefällt mir

    • Uli Armbruster 27. April 2014 um 16:14 Reply

      Gebe ich dir vollkommen recht. Das ist aber ein Grundpfeiler aller Meinungsmacher und Entscheidungsträger, nicht nur z.B. von Vorgesetzten (was ein PO ohnehin nicht ist!). Ich habe oben geschrieben: „In seiner aktuellen Aufgabe hatte unser Admin sehr engen und guten Kontakt zu allen“ <- das ist vielleicht nicht deutlich genug gewesen, ist aber das, was du du richtig angesprochen hast.
      Prinzipiell denke ich dass es sogar von Vorteil ist, wenn der PO in der klassischen Unternehmensführung keine Führungsfunktion ausübt, damit nicht die Tendenz der Rolle hin zum klassischen Projekt Manager ausschlägt. Dann passiert das, wovon viele berichten, nämlich dass der PO auf Kompetenzen des Developer Teams Einfluss nimmt. Inwieweit so etwas in großen Unternehmen möglich ist, kann ich auf Grund mangelnder Erfahrung nicht sagen. Die heco ist ein familiengeführtes, mittelständisches Unternehmen und der GF suchte ohnehin nach einer Möglichkeit sich ein Stück weit entbehrlich zu machen und sein Inselwissen weiterzugeben. Vielleicht haben es deshalb Scrum Teams in kleineren Firmen einfacher, weil die Rolle des PO nicht zu stark verwässert und der eines Projekt Managers gleicht. Aber das ist jetzt Spekulation.

      Gefällt mir

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: