Ist es eine gute Idee, eines der Mitglieder des Scrum-Teams oder des Scrum-Masters zum Product Owner zu ernennen?

In letzter Zeit hatten wir ein Projekt, bei dem der Kunde gerade auf Tour war. Da das Scrum-Team wie gewohnt gebildet wurde, hat das Management beschlossen, unseren Analysten zum Product Owner zu ernennen, da der Kunde nicht aktiv teilnehmen kann. Analyst war derjenige, der eng mit dem Kunden bei der Anforderungsanalyse und der Erstellung von Spezifikationen zusammengearbeitet hat.

Der Kunde hat keine Zeit, die ersten beiden Versionen zu überprüfen. Alles verlief reibungslos, bis der Kunde die dritte Veröffentlichung sah. Er war mit einigen Funktionen nicht zufrieden, und diese wurden von make shift Product Owner (unserem Analysten) vorgestellt.

Wir sollten warten, bis das Designteam das Mock-up aller Seiten abgeschlossen hatte, und der Kunde überprüfte jede Seite und genehmigte die Fortsetzung der Arbeit. Das Scrum-Team ist da, aber keine Sprints - wir haben die Arbeit fast wie bei einer klassischen Wasserfallmethode beendet.

Ist es eine gute Idee, ein Scrum-Teammitglied oder einen Master zum Product Owner zu ernennen? Müssen wir scrum folgen, wenn der Kunde / Produktbesitzer nicht beteiligt ist?

Erst vor wenigen Wochen schrieb Mike Cohn in seinem Blog über das Kombinieren von Scrum-Master- und Product-Owner-Rollen. Ich glaube nicht, dass ich es besser ausdrücken kann als er, aber meine kurze Zusammenfassung seines Beitrags lautet:

• Es ist eine schlechte Idee
• SM und PO erledigen sehr unterschiedliche Aufgaben ("Staraufgaben" und "Wächteraufgaben" in Cohns Worten)
• Es ist unwahrscheinlich, dass die Person, die die beiden Rollen kombiniert, zu allen Aufgaben in beiden Rollen passt
• Das Team kann dadurch verletzt werden, dass die kombinierte SM / PO die Aufgaben vernachlässigt, bei denen sie nicht die Besten sind.

Ich denke, es ist per se nichts Falsches daran, ein Mitglied eines Scrum-Teams zu nehmen und es zum Product Owner zu bewegen. Aber Sie müssen sich darüber im Klaren sein, dass es sich um eine Beförderung oder einen internen Transfer handelt. es entsteht ein loch im team und das loch muss gefüllt werden. Vielleicht kann sich das Team "selbst reorganisieren", um die Lücke zu füllen. Möglicherweise muss ein neuer Mitarbeiter eingestellt werden, um die vakante Position zu besetzen.

Ihr Prozess scheint mir in Ordnung zu sein. Sie haben es nicht im Detail beschrieben, aber zumindest werden die Rollen respektiert (das ist wichtig).

Aufgrund der wenigen Details, die ich habe, kann ich jedoch Probleme auf der Ebene der Product Owner feststellen.

Er sollte sicherstellen, dass der Kunde über den Fortschritt ordnungsgemäß informiert wird. Sieht so aus, als würde er extern mit dem Kunden "Wasserfall" machen und intern mit Ihnen "scrum".

Ergebnis : Wasserfall gewinnt, da Kunde König ist. Auch wenn in diesem Fall der Kunde seine Verantwortung hat ...

Ihr aktuelles Team (einschließlich Scrum Master) sollte sich darauf konzentrieren, das Sprint-Backlog bereitzustellen. Der Product Owner (Analyst) sollte jedoch sicherstellen, dass das, was sich in seinem Backlog befindet, dem entspricht, was der Kunde wünscht. Sie / er sollte auch sicherstellen, dass die Kommunikation gut ist und dass der Kunde teilnimmt.

Mögliche Lösung : Senden Sie Ihren Product Owner (Analyst) an einen Scrum Product Owner-Kurs , oder lassen Sie ihn dieses Buch lesen (und verstehen): Agiles Produktmanagement mit Scrum .

Scrum funktioniert am besten mit einem echten Kunden. Es gibt ein paar echte Herausforderungen im Umgang mit Kunden, die nicht an iteratives Produktdesign gewöhnt sind.

• Das Blank Sheet Syndrom
• Angst Klientensyndrom

Entwurfsphasen mit einem leeren Blatt gehen in der Regel sehr schnell in den Himmel und gehen in der Regel auf einige Nebenaspekte ein und auf die Kernfunktionalität, die benötigt wird, nicht ausreichend ein. Sie brauchen wirklich einen Strohmann, den der Kunde auswählen kann, damit die Designtreffen erfolgreich verlaufen. Indem Sie sich jeweils nur auf einen Aspekt konzentrieren, helfen Sie Ihrem Kunden, iteratives Design zu erlernen.

Verängstigte Kunden (wie Sie es mit Ihrer Erfahrung getan haben) merken nicht, dass agile Projekte einen gewissen (kontrollierten) Nacharbeitsaufwand als Teil des Prozesses erwarten. Es fällt ihnen schwer zu begreifen, dass es mit der Weiterentwicklung der Produkte weniger "Oh mein Gott" -Momente geben wird. Noch wichtiger ist, dass die meisten Kunden Schwierigkeiten damit haben, die "Oh mein Gott" -Momente aufgrund der kurzen Zeit zwischen den Überprüfungs- / Planungszyklen ohne viel Geld zu reparieren.

Das Management der Kundenerwartungen ist sehr schwierig. Es ist ein ausgewogenes Verhältnis zwischen Kundenerziehung, Beschwichtigung und sogar dem Lernen, "Nein" zu sagen. Der Kunde kann nicht immer wöchentlich oder zweiwöchentlich kommen. Manchmal können sie nur einmal im Monat kommen. Das ist okay. Solange Sie ihnen zeigen, was Sie getan haben, um ihre Bedenken im Vormonat auszuräumen, und sich dann auf die Arbeit dieses Monats konzentrieren, trägt dies wesentlich dazu bei, dass das Projekt reibungsloser verläuft. Fazit ist, dass Sie in Abwesenheit des Kunden jemanden haben, der vernünftige Empfehlungen für einige Fragen geben kann. Es muss jemand sein, der mit den Zielen, die der Kunde zu erreichen versucht, vertraut ist.

Im Idealfall verfügt der Product Owner über ein gewisses Maß an Autorität und Wissen über das Projekt. Dasselbe hätte passieren können, wenn der Kunde einen untergeordneten Mitarbeiter zugewiesen hätte, der zu einem späteren Zeitpunkt außer Kraft gesetzt wurde, sodass Sie fast von vorne anfangen müssten.

Danke für deinen Beitrag. Mir ist klar, dass es alt ist, aber ich denke, Sie haben einen großartigen Fall angesprochen und hier sind meine $ .02:

Problem 1: Wenn Sie den Analysten in Ihrem Fall als PO festlegen, wird das Scrum-Framework ernsthaft kurzgeschlossen. Warum? Denn nur die PO kann Werturteile, ROI-Bewertungen, Prioritäten und entscheidende Entscheidungen treffen, die sich aus dem Geschäft ergeben, nicht aus der Technologie, nicht einmal aus der Vertrautheit mit dem Produkt. Ich bin sicher, Ihr sr. Der Analyst hat einen fantastischen Job gemacht, der die Bestellung imitiert, musste aber letztendlich die Wünsche, Werte und Entscheidungen erraten, die von Ihrer Bestellung kommen würden. ref http://kenschwaber.wordpress.com/2011/01/31/product-owners-not-proxies/ . Solange Ihrem Analysten keine POA vom Kunden gewährt wurde (unwahrscheinlich), wäre er nicht in der Lage, beim Sprint-Review etwas zu akzeptieren oder abzulehnen.

Könnte dieser Ansatz möglicherweise funktionieren? Ja, aber es müsste eine vollständige Übertragung von Verantwortlichkeiten geben, solange Ihr Kunde nicht da ist. Der Chef Ihres Kunden müsste dem Ersatz zustimmen, und keine vernünftigen Entscheidungen würden rückgängig gemacht. Hört sich das wahrscheinlich an? Wahrscheinlicher ist, dass Sie eine vorübergehende Bestellung von der Organisation Ihres Kunden erhalten würden (was sicherlich nicht ohne Nachteile ist!). Aber wenn Ihre sr. Der Analytiker arbeitete mit der vorübergehenden Bestellung, alle falschen Entscheidungen würden vom Geschäft kommen, wodurch Ihre Teamrollen sauber gehalten würden.

Problem 2: "Client hat keine Zeit zum Überprüfen". Großes Problem (und eines, auf das ich kürzlich auch gestoßen bin). PO muss vorhanden sein, um das Produkt zu akzeptieren. Niemand sonst kann den Scheck unterschreiben. PO-Abwesenheit bedeutet, dass Unzufriedenheit später eintritt, möglicherweise mehr Nacharbeit und Vertrauensverlust. Grundsätzlich habe ich das Gefühl, dass der Kunde nicht aktiv in Ihr Projekt involviert ist: keine Zeit für das tägliche Aufstehen, keine Zeit für die Beantwortung von Fragen usw.

Problem 3: "Wir sollten warten, bis das Designteam das Mock-up beendet hat". Und jetzt sind wir komplett außer Atem. Die Leute, die das Mock-up machen, sollten Teil Ihres funktionsübergreifenden Teams sein. Ich kann nicht sagen, ob dies auf mangelndes Managementverständnis für Scrum oder eine Schockreaktion auf Ihre dritte Veröffentlichung zurückzuführen ist.

Frage: Wo war dein Scrum Master in all dem? Die SM würden normalerweise die Gefahr des Rollenkonflikts und die mangelnde Beteiligung der PO erkennen, wobei beide Hindernisse / Gefahren angegangen werden müssten.