Scrum: Was ist, wenn der Product Owner Aufgaben hat?

Ich habe gerade angefangen, mit einem Team zu arbeiten, das einige Aspekte von Scrum (zweiwöchiges Timeboxing) aufgegriffen hat, andere jedoch nicht (das Team stimmt derzeit nicht allen Schätzungen oder der Anzahl der Punkte in einem Sprint zu, aber ich werde dies ändern bald.) Der Product Owner ist auch eine technische Ressource (Wissenschaftler) mit einem gewissen Entwicklungshintergrund.

Ist es angemessen, die Aufgaben des Produktbesitzers (die hauptsächlich Forschung beinhalten) mit den Aufgaben des Teams (von denen einige Forschung und einige Entwicklung sind) zu mischen?

Scrum-Experten sind sehr fest davon überzeugt, dass der Product Owner und der Scrum Master zwei verschiedene Personen sein sollten. Es gibt jedoch keine solche Regel, die das Entwicklungsteam ausschließt. Hinweis im Scrum Guide :

Größe des Entwicklungsteams

Die optimale Größe des Entwicklungsteams ist klein genug, um flink zu bleiben, und groß genug, um wichtige Arbeiten abzuschließen. Weniger als drei Mitglieder des Entwicklungsteams verringern die Interaktion und führen zu geringeren Produktivitätsgewinnen. Kleinere Entwicklungsteams können während des Sprints auf Einschränkungen der Fähigkeiten stoßen, was dazu führt, dass das Entwicklungsteam kein potenziell freisetzbares Inkrement liefern kann. Mehr als neun Mitglieder zu haben, erfordert zu viel Koordination. Große Entwicklungsteams erzeugen zu viel Komplexität, als dass ein empirischer Prozess verwaltet werden könnte. Die Rollen Product Owner und Scrum Master sind in dieser Zählung nicht enthalten, es sei denn, sie führen auch die Arbeit des Sprint-Backlogs aus.

Die Folge dieser letzten Zeile wäre, dass der Product Owner, wenn er die Arbeit des Sprint Backlog ausführt, als Mitglied des Entwicklungsteams gezählt wird.

Das heißt, tun Sie alles, um Ihre Arbeit gut zu machen.

Der Product Owner ist dafür verantwortlich, den Wert und die Kapitalrendite des Produkts zu maximieren. Es mag einfach erscheinen, aber es ist normalerweise eine Vollzeit- und sehr anspruchsvolle Rolle - wohl die schwierigste in Scrum. Es beinhaltet eine Menge strategischer Arbeit auf hoher Ebene sowie Aufgaben auf niedrigerer Ebene, von der Analyse von Marktchancen und der Konsultation der Stakeholder und Benutzer des Produkts, um die richtigen Entscheidungen zu treffen, bis hin zur ständigen Aktualisierung der Produkt-Roadmap und des Auftragsbestands, der Überwachung und der Planung Überprüfen Sie die Aktivitäten, stellen Sie sich dem Team zur Verfügung, um ihre Fragen zu beantworten usw.

Wenn die PO für andere Aufgaben zuständig ist, würde ich sie in den meisten Fällen nur als marginal ansehen. Meine Antwort wäre also: Ja, erstellen Sie Aufgaben für die Bestellung, wenn Sie dies wirklich müssen und wenn sie direkt zur Erstellung des Software-Inkrements des Sprints beitragen, aber ich sehe, dass dies in einem durchschnittlichen Scrum-Projekt nicht häufig vorkommt.

Bei Scrum geht es in erster Linie um Kommunikation und um relevante und zeitnahe Arbeiten. Alles, um dieses Ziel zu erreichen, ist in Ordnung, wenn Ihr Team dadurch am produktivsten ist.

Es ist jedoch schwierig, es gut zu machen. Ich bin jetzt in dieser Position und es fällt mir schwer, als Product Owner eine angemessene Zeit zu investieren, während ich noch Zeit für die Entwicklung habe. Das Arrangement funktioniert jedoch zu diesem Zeitpunkt gut für dieses spezielle Team. Wir werden die Entscheidung für mich überdenken, die doppelte Pflicht zu übernehmen, wenn unsere Leistung sinkt, aber bis dahin werden wir so weiterarbeiten.

Also probieren Sie es aus. Machen Sie Rückblicke, damit Sie Ihren Prozess kontinuierlich verbessern können. Lassen Sie nicht zu, dass das Festhalten an einer Methodik die Produktivität Ihres Teams beeinträchtigt.