Macht es in Scrum jemals Sinn, einen Product Owner einzustellen?

Ich habe ein Scrum-Team gesehen, das versucht hat, einen Product Owner einzustellen. Sie werben für Scrum-Fähigkeiten und Erfahrung.

Ist es sinnvoll, einen Product Owner von außerhalb des Unternehmens einzustellen?

Wenn ich das tue, welche Fähigkeiten sollten sie haben?

Meinst du wie ein Berater oder ein Auftragnehmer? Oder nur eine allgemeine Neueinstellung?
Ich habe eine Anzeige für eine Product-Owner-Rolle gesehen. Es konzentriert sich zu 100 % auf Scrum-Fähigkeiten, keine Erwähnung des Produkts oder dessen, was das Unternehmen tut. Dann ist mir aufgefallen, dass viele Jobs für einen Product Owner ausgeschrieben sind, obwohl ich keine davon gelesen habe.
So seltsam das auch erscheinen mag, meiner Erfahrung nach ist es schwieriger, eine Person zu finden, die in Scrum und der PO-Rolle gut ausgebildet ist, als jemanden mit Kenntnissen zu diesem Thema zu finden, da das Thema für die meisten Unternehmen trivial ist (die meisten Leute verkaufen Sachen oder Services, das ist nicht wirklich Raketenwissenschaft), aber anscheinend ist das Lesen und Verstehen eines 100-seitigen Buches über Scrum weit außerhalb der persönlichen Komfortzone der Menschen, wenn sie keine Entwickler sind.
@nvoigt das sieht aus wie eine Antwort, eine kurze Antwort, aber eine Antwort. (es scheint ungefähr die richtige Größe für das zu sein, was du zu sagen hast)
@nvoigt ein 100-seitiges Buch? Sie sollten stattdessen den 15-seitigen Scrum-Leitfaden lesen. Aber selbst das scheint vielen Leuten, die behaupten, es zu benutzen, entgangen zu sein.

Antworten (4)

Zusammenfassung

Ist es sinnvoll, einen Product Owner von außerhalb des Unternehmens einzustellen? Wenn ich das tue, welche Fähigkeiten sollten sie haben?

Vielleicht. Eine bessere Frage ist, ob jemand innerhalb oder außerhalb des Unternehmens eine bessere Vision für ein bestimmtes Produkt hat. Ich persönlich war als externer Product Owner erfolgreich und habe sowohl erfolgreiche als auch scheiternde interne Product Owner erlebt. Die Antwort lautet also wie üblich „es kommt darauf an“.

Analyse

Der Scrum Guide beschreibt die Rolle des Product Owners wie folgt:

Der Product Owner ist dafür verantwortlich, den Wert des Produkts, das aus der Arbeit des Entwicklungsteams resultiert, zu maximieren. Wie dies durchgeführt wird, kann je nach Organisation, Scrum-Team und Einzelpersonen stark variieren.

Der Product Owner ist die einzige Person, die für die Verwaltung des Product Backlogs verantwortlich ist. Das Product Backlog Management umfasst:

  • Produkt-Backlog-Einträge klar ausdrücken;
  • Ordnen der Elemente im Product Backlog, um Ziele und Missionen am besten zu erreichen;
  • Optimierung des Werts der Arbeit, die das Entwicklungsteam leistet;
  • Sicherstellen, dass das Product Backlog für alle sichtbar, transparent und klar ist und zeigt, woran das Scrum-Team als Nächstes arbeiten wird; und,
  • Sicherstellen, dass das Entwicklungsteam die Elemente im Product Backlog auf dem erforderlichen Niveau versteht.

Pragmatisch gesprochen braucht ein Product Owner, um das Product Backlog zu verwalten und den Wert zu optimieren:

  • eine starke und gut kommunizierte Vision für das Produkt; und
  • ausreichendes Wissen über das Produkt, seine Funktionen und sein Leistungsversprechen, um Funktionen priorisieren und iterative Ziele für das Scrum-Team definieren zu können.

In der Praxis bedeutet dies, dass die besten Product Owner Erfahrung in der Domäne des Produkts haben und der ideale Product Owner auch Erfahrung mit dem Unternehmen, seinen Stakeholdern und seinen Kunden hat.

Keines dieser Dinge sind streng genommen Vorabanforderungen an jemanden, der der Rolle zugewiesen ist. Ein Product Owner kann in die Rolle hineinwachsen und das wesentliche Wissen über den Lebenszyklus des Projekts erlangen. Eine Person, der diese Dinge fehlen, wird jedoch wahrscheinlich eher als Proxy Product Owner und nicht als eigentlicher Entscheidungsträger für das Projekt beginnen. Dies widerspricht dem Geist von Scrum, der besagt:

Der Product Owner ist eine Person, kein Komitee. Der Product Owner kann die Wünsche eines Komitees im Product Backlog vertreten, aber diejenigen, die die Priorität eines Product Backlog-Eintrags ändern möchten, müssen sich an den Product Owner wenden.

In mancher Hinsicht definiert der Product Owner das Produkt. Es ist also unwahrscheinlich, dass ein Product Owner ohne ausreichende Vision oder Kenntnisse, um das Projekt voranzutreiben, in dieser Rolle erfolgreich sein wird. Darüber hinaus ist es unwahrscheinlich, dass ein Projekt ohne starke Product Owner-Rolle reibungslos funktioniert oder einen Spitzenwert liefert.

All dies mag auf die Vorstellung hindeuten, dass ein Product Owner aus einem Unternehmen kommen sollte, aber das stimmt nicht unbedingt. Manchmal kann eine externe Perspektive von jemandem, der über fundierte Kenntnisse eines Marktes oder Erfahrung mit der Lieferung ähnlicher Produkte verfügt, außerordentlich wertvoll sein.

Scrum ist ein Teamsport und es ist schwer erfolgreich zu sein, wenn dem Team ein starker Spieler in einer Schlüsselrolle fehlt. Am Ende zählt weniger „innen“ oder „außen“, als sicherzustellen, dass die Person, die die Rolle ausfüllt, die richtige Person mit der richtigen Mischung aus Kenntnissen und Fähigkeiten ist und zum Unternehmen und zum Scrum-Team passt.

TL;DR : Wahrscheinlich nicht, es sei denn, sie bringen Schlüsselkompetenzen mit, die Sie in Ihrem Unternehmen noch nicht hatten.

Es hängt davon ab, dass die meisten Product Owner, die ich in Teams gesehen habe, das sind, was ich als Proxy Product Owner bezeichnen würde . Geschäftsanforderungen in Geschichten übersetzen und Stakeholdern dabei helfen, zwischen ihnen Prioritäten zu setzen. Das Team abschirmen und gleichzeitig verstehen, was technische Schulden bedeuten, und genügend Geschäftswissen sammeln, um die täglichen Anforderungen des Scrum-Teams zu erfüllen. Trotzdem würde ich selbst für diese Rolle jemanden aus dem Unternehmen bevorzugen, weil er Domänenwissen mitbringt und vielleicht zu einem echten Product Owner heranwachsen kann.

Ein unternehmerischer Product Owner. Jemand, dem das Produkt gehört. Jemand, der Strategie und Vision vorgibt. Dies ist wahrscheinlich niemand, den Sie in das Unternehmen einstellen können. Es sei denn, diese Person bringt fachliches Domänenwissen ein, das Sie für das Produkt benötigen, das sonst in Ihrem Unternehmen noch nicht vorhanden ist.

Es kommt auch auf deine Waage an. Möglicherweise haben Sie einen Chief Product Owner und einige Area Product Owner . Sie sollten ihren Bereich besitzen oder sie sind auch nur Stellvertreter.

Für Proxy- und Area-Product-Owner könnten Sie also einen schnellen Lerner mit Erfahrung als Scrum-Product-Owner für ein einzelnes Scrum-Team einstellen. Dies könnte sie schnell auf Geschwindigkeit bringen. Dies kann sinnvoll sein, wenn Sie viele Teams haben, sagen wir drei oder mehr.

Wenn Sie jemanden suchen, der Ihr Geschäft ausbaut und EIGENTUM des Produkts ist, kann ich mich nicht um seine aktuellen Scrum-Fähigkeiten kümmern, die wir unterrichten können. Geschäftssinn, Expertenwissen und ein gutes Gespür für langfristige Strategien in Ihrer Branche sind etwas schwieriger zu trainieren.

Eindeutiges NEIN, wenn es Ihr erster Product Owner ist, es sei denn, er bringt neben den Scrum-Fähigkeiten etwas wirklich Besonderes mit: ein Vertriebsnetz, fundierte Branchenkenntnisse, Finanzierung usw.

Ich habe Waterfall-Agile-Unternehmen in Deutschland gesehen, die Product Owner einstellen, um Ideen in lange Listen von Epics und Stories aufzuteilen. Dies sind eher Analysten für Geschäftsanforderungen. Eine Art Proxy-Produktbesitzer, aber schlimmer.

Es hängt also von der Art des Product Owners ab, nach dem Sie suchen, aber nach einem echten Product Owner, wie Scrum es beabsichtigt hat. Nein, es macht keinen Sinn.

Wie würde sich überhaupt ein erstes Scrum-Team bilden, wenn der PO bestimmungsgemäß bereits Erfahrung als PO in diesem Bereich haben muss? Ist das nicht ein Henne-Ei-Problem?
@nvoigt Nein keine Erfahrung als Scrum PO. Wie ich bereits sagte, können Sie Menschen leicht schulen, um sich Scrum PO-Fähigkeiten anzueignen. Es macht keinen Sinn, jemanden mit nur PO-Scrum-Kenntnissen, aber ohne Branchenkenntnisse einzustellen. Vertrauen Sie mir, ich habe gesehen, wie Unternehmen dies tun. Stellen Sie POs ein, weil sie wissen, wie man Geschichten macht...
Das erste Scrum-Team würde sich aus einigen Entwicklern, einem Kaufmann und einem Scrum Master bilden, der sie schult. Dieser Kaufmann muss nicht von vornherein ausgebildeter PO sein.
Ich denke, wir haben wahrscheinlich unterschiedliche Erfahrungen. Ich würde jemanden, der PO werden möchte und Branchenerfahrung sammeln muss, jemandem vorziehen, der die Branche kennt, aber tatsächlich einen anderen Job hatte. Einige der schlimmsten POs, die ich getroffen habe, waren Leute, die in diese Rolle „sanft hineingeschubst“ wurden, als ihr Unternehmen auf agil umstellte. Ex-Projektmanager, Ex-Business-Analysten. Wenn jemand ein PM werden möchte, ist es meiner Erfahrung nach besser, dass er ein großartiger PM an anderer Stelle wird, anstatt ein lausiger PO mit Geschäftserfahrung zu sein. Sicher, Sie können Glück haben und einen tollen Ex-Etwas PO bekommen, aber Sie könnten genauso gut Glück haben, wenn Sie draußen anstellen.
Ich verstehe Ihre Ansicht, und wenn Sie Rollen wie PM, BA fallen lassen. Zur Hölle, nein, ich würde wollen, dass sie POs werden. Ich dachte eher an Ex-Betriebsmitarbeiter oder Start-up-Gründer, Menschen, die tatsächlich gearbeitet haben. Menschen, die kreativ sind und keine Karriere im Management anstreben. Die visionären Talente Ihres Unternehmens. Ich habe hauptsächlich mit Unternehmen mit 50-100 Mitarbeitern gearbeitet, vielleicht wäre es für ein Unternehmen sinnvoll, von außerhalb mit etwas Erfahrung einzustellen. Aber Unternehmen sind sowieso sehr un-agil, also warum sich die Mühe machen :)

TL;DR: Sicher, wo sonst würden Sie einen mieten?

Ist es sinnvoll, einen Product Owner von außerhalb des Unternehmens einzustellen?

Sicher warum nicht. Sie stellen alle Ihre anderen Mitarbeiter von außerhalb des Unternehmens ein, Product Owner wachsen nicht auf magischen Bäumen im Keller. Es ist ein Job wie Scrum Master oder Mitglied des Entwicklungsteams. Du brauchst einen, du mietest einen.

Wenn ich das tue, welche Fähigkeiten sollten sie haben?

Sie sollten Scrum (natürlich) kennen und Erfahrung in ihrem Fachgebiet haben. Sie würden auch nicht irgendeinen Entwickler einstellen , um Ihr Produkt zu entwickeln. Wenn zum Beispiel ein medizinisches Unternehmen einstellt, erwarte ich optionale medizinische Anforderungen, ein Hersteller für eingebettete Autoteile möchte möglicherweise Erfahrung in diesem Teil haben. Aber am Ende gilt das für alle Rollen. Jeder Product Owner baut ein Produkt für andere, die Kunden. Zu verstehen, was der Kunde will, ist ein wichtiger Teil, und der PO muss den Überblick behalten und dies ständig in neue User Stories einfließen lassen. Anzunehmen, dass der PO mit diesem bereits vorhandenen Wissen kommen könnte, ist gefährlich. Sicher, Menschen mit Erfahrung haben einen Vorsprung, aber das Lernen und Anpassen ist ein wichtiger Teil ihrer Arbeit, daher sollte jeder potenzielle PO in der Lage sein, bei Null anzufangen.

+1 "Lernen und Anpassen ist ein wichtiger Teil ihrer Arbeit, daher sollte jeder potenzielle PO in der Lage sein, bei Null anzufangen". Ich mag diesen Gedanken wirklich.

Todd A. Jacobs und Niels van Reijmersdal haben wirklich hervorragende Antworten auf eine gute Frage gegeben.

Hier ist meine Wendung:

Wenn ich mich entscheiden müsste

a) ein erfahrener PO aus einer anderen Branche

b) ein Fachexperte mit nicht der geringsten Ahnung von Produkteigentum

was würde ich wählen?

Ich denke nicht, dass a) unbedingt die falsche Wahl ist. Ein erfahrener PO, der bereit ist, die Domain zu wechseln, wird bereits wissen, dass er sich sehr schnell auf den neuesten Stand bringen muss, da er eine sehr steile Lernkurve hat. Ich habe mit einer Person gearbeitet, die dies sehr erfolgreich gemacht hat, der Rest ist schnell gescheitert.

Meine Wahl wäre also b), aber nur unter der Bedingung, dass sie sich voll und ganz dem Erlernen des Produktbesitzes verschrieben haben, was als eigenständige Subdomäne betrachtet werden kann. Ich denke, es gibt Produkte, die Domänenkenntnisse erfordern, die man sich als PO nicht im Job aneignen kann. Zum Beispiel braucht ein Produkt, das von Chirurgen verwendet wird, einen Produkteigentümer, der ein Chirurg ist (oder ein gleichwertiger Domänenexperte, sofern dies möglich ist), und es gibt keinen schnellen Weg, um Chirurg zu werden (hoffen wir!). Aber finden Sie einen Chirurgen, der sich für die Welt von Scrum und Agile interessiert?

Mein „Test“ ist die Konferenzsaison. Es gibt eine bevorstehende Konferenz für Chirurgen: Kann Ihr „Karriere-PO“ die Aussagen der Redner genug einschätzen, um ihre Entscheidungen über das Produkt zu beeinflussen? Es gibt einen zeitlichen Konflikt zwischen der führenden Konferenz für Chirurgen und der besten Agile-Konferenz der Saison: Wird Ihr „Chirurgen-PO“ die Agile-Konferenz wählen, um sein Lernen zu unterstützen?

Macht es in Scrum jemals Sinn, einen Product Owner einzustellen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v