Auf welcher Ebene sollte der Product Owner die Arbeit priorisieren?

Scrum ist am effektivsten, wenn es einen Backlog und einen Product Owner für ein Lieferteam gibt.

Das Backlog ist so konzipiert, dass die zu beginnende Arbeit auf der User-Story-Ebene definiert wird , was für das Delivery-Team bequem zu bearbeiten ist. Aber der Rückstand kann auch geplante Arbeiten enthalten, die mehrere Wochen oder sogar Monate entfernt sind. Diese Arbeit kann manchmal ziemlich grob definiert werden und wird durch „Epen“ oder „Themen“ repräsentiert . Dies kommt in Scrum wahrscheinlich dem von Ihnen erwähnten „Projekt A“, „Projekt B“ und „Projekt C“ am nächsten.

Die Idee ist, dass der Product Owner das Backlog kontinuierlich verfeinert. Sie brechen die grob definierte Arbeit just-in-time in konkretere User Stories herunter. So dass die Arbeit, mit der begonnen werden soll, gut definiert ist, die zukünftige Arbeit jedoch möglicherweise weniger klar ist.

Obwohl der Product Owner für das Backlog verantwortlich ist, bedeutet das nicht, dass er die einzige Person ist, die daran arbeitet. Es ist durchaus üblich, dass der Scrum Master und das Lieferteam mit dem Product Owner zusammensitzen und ihm bei der Aufgabe helfen, zukünftige Arbeiten in User Stories aufzuteilen. Dies ist besonders häufig der Fall, wenn der Product Owner nicht sehr erfahren in der Rolle ist.

Meine erste Empfehlung wäre, vorzuschlagen, dass die Person, die derzeit in der Rolle des Product Owners ist, eine Schulung erhält. Die Product Owner-Zertifizierung ist ideal und umfasst normalerweise nur ein paar Schulungstage.

Zweitens, lassen Sie den Scrum Master und das Team mit dem Product Owner zusammenarbeiten, um ihnen zu helfen, die schlecht definierte Arbeit in Anforderungen zu zerlegen, mit denen das Team arbeiten kann. Ich würde vorschlagen, dass Sie dies im Rahmen von Backlog-Refinement- Meetings tun, die ziemlich häufig stattfinden. Sie werden vielleicht feststellen, dass der Product Owner, nachdem Sie dies ein paar Mal getan haben, beginnt, das Konzept zu verstehen, und dann einen Großteil der Verfeinerung selbst vornehmen wird.

Es scheint, dass Sie ein Problem mit einem kohärenten Sprintziel haben .

Ich weiß nicht, wie das Team Product(s) Backlog nutzt, aber Sie sollten gegenüber dem PO betonen, dass das Team umso effizienter arbeitet, je kohärenter der Sprint-Inhalt ist. Wenn jedes Mitglied an seinem eigenen Thema arbeitet, ist es nicht wirklich Scrum (ich meine die ursprüngliche Bedeutung von Rugby ). Um die Vorteile von Scrum (Framework) zu nutzen, muss das gesamte Team das eine gemeinsame Ziel des Sprints haben, um die Zusammenarbeit und Selbstorganisation zu verbessern.

Eine Sache noch. In dem von Ihnen erwähnten Beitrag:

Angeblich organisiert ein großartiger Product Owner Artikel nach Priorität, um die Arbeitsmenge zu maximieren, die das Team erledigen kann.

Der Product Owner ist hier, um den ROI (Return on Investment) des Projekts zu maximieren, nicht den Arbeitsaufwand. PO sollte das Product Backlog so ordnen, dass das Projekt bei jeder Iteration den maximal möglichen Wert liefert (damit das Team zuerst an den wichtigsten Elementen arbeitet).

Wie ich aus dem, was Sie bisher angegeben haben, verstehe, ist Ihr Symptom:

Es gibt immer konkurrierende Gegenstände für die Entwicklungszeit

Dies ist an sich eine ganz normale Herausforderung des (Software-Entwickler-)Lebens, für deren Bewältigung der Product Owner verantwortlich ist. Bisher scheinen Sie auf dem richtigen Weg zu sein, nur scheint das Problem zu sein, dass Sie mehrere Projekte für ein Team haben, mit engagierten Leuten im Team für jedes Projekt. Für den Fall, dass die verschiedenen Projekte keine gegenseitige Abhängigkeit haben, würde ich empfehlen, die Teams in kleinere aufzuteilen - jedes besteht aus dem Entwicklerteam, das an einem Produkt-Backlog für eines der Projekte arbeitet, die Sie haben.

Wenn die Aufteilung des Teams (aufgrund von Abhängigkeiten) keine Option ist, müssen Sie alle Projekte in ein Backlog für das eine Team aufnehmen, das Sie haben. Dann liegt es wieder am PO, über Prioritäten innerhalb dieses Rückstands zu entscheiden. Und ja, es ist normal, dass dies für die PO eine Herausforderung darstellt. Im Allgemeinen können Sie ein Backlog für mehrere Teams haben – aber Sie können nicht mehrere Backlogs für ein Team haben.

Was ist ein effektiver Weg, um den Product Owner und Stakeholder bezüglich seines Führungsstils zu korrigieren?

Sie haben nicht gesagt, warum Sie dies tun möchten, bedenken Sie, welches Problem durch diesen Führungsstil verursacht wird, das wird Ihr Hebel zur Korrektur sein.

Beachten Sie jedoch, dass der PO zwar für den Rückstand verantwortlich ist, aber nicht die einzige Person ist, die einen Beitrag dazu leistet. Das Scrum-Team sollte alle Beiträge liefern, die der PO berücksichtigt. Geht das hier? Hat der PO eine PSM-Zertifizierung?

Wie andere Shave gesagt haben, funktioniert es nicht wirklich, ein einziges Scrum zu haben, um an mehreren Projekten zu arbeiten, erwägen Sie, das Team aufzulösen. Beachten Sie, dass dies ein kleines Unternehmen ist, aber auch hier könnte Schulung hilfreich sein, aber Scrum ist aus einem bestimmten Grund so eingerichtet. Geben Sie dem Projekt, das es benötigt, Priorität und fahren Sie dann mit dem nächsten Projekt fort.

In Bezug auf den Rückstand muss der PO ihn organisieren, um den besten ROI zu erzielen. Sie haben nicht gesagt, ob dies hier geschieht, denn wenn dies nicht der Fall ist, können Sie ihm vielleicht zeigen, wie es besser funktionieren könnte, indem Sie Folgendes bereitstellen: ein besser strukturiertes Backlog, etwas Training etc

Zusammenfassend lässt sich sagen, dass Sie anscheinend kein Scrum haben, sondern stattdessen die von Scrum bereitgestellten Titel verwenden, um die Standardpraxis fortzusetzen. Dies kann auf mangelndes Training zurückzuführen sein, ist aber auch auf mangelnde Standardisierung zwischen Organisationen in Bezug auf agile Konzepte und Umsetzung zurückzuführen.

Mir scheint, dass die gesamte Organisation von der Spitze bis zum Scrum-Team das Konzept von Aufgaben und Selbstorganisation lernen muss.

Es ist für eine Organisation nicht verkehrt, mehrere Projekte gleichzeitig laufen zu lassen. Allerdings muss dem Projekt entsprechend seiner Wertschöpfung und Dringlichkeit für die Organisation Priorität eingeräumt werden.

Es ist nicht gesund, dass der PO das Entwicklungsteam aus einer Quelle zieht und einem anderen laufenden Projekt zuweist. Was hier am besten getan werden könnte, ist von der PO aus, das Entwicklungsteam in die Anzahl der gleichzeitig laufenden Projekte aufzuteilen und jedes Entwicklungsteam einem Produkt zuzuweisen, damit die Teammitglieder ihre Ergebnisse verstehen können. Projekt A zum Beispiel sollte einen eigenen Product Backlog haben und PBIs sollten verfeinert und in einen priorisierten Sprint verschoben werden, basierend auf der Tarifvereinbarung des gesamten Scrum-Teams und dem Wert, den solche Elemente auf den Tisch bringen. Auch für andere Projekte sollten die Räder neu erfunden werden.

Es ist auch erwähnenswert, dass ein Scrum Master nur ein Scrum-Team gleichzeitig leiten kann. Das Mikromanagement mehrerer Teams innerhalb einer Organisation ist keine gute Idee, stattdessen sollte das Scrum-Team ein Projekt abschließen, bevor es sich entscheidet, ein anderes zu starten.

Sie haben ein Problem ... der Product Owner ist kein echter Product Owner, also weiß er nichts über Agilität, also wird Scrum niemals so funktionieren, es sei denn, Sie finden einen richtigen Product Owner.

Wie der Scrum-Leitfaden sagt, helfen Management, Stakeholder in diesem Fall dem Unternehmen bei der Implementierung von Scrum, sind aber nicht Teil davon, erst recht in diesem Fall, wenn die Person keine Ahnung von Agilität hat.

Die Denkweise hinter dem, was Sie beschreiben, ist nicht für Scrum gedacht, verwenden Sie stattdessen Kanban und Sie werden die Vorteile sehen. Das Unternehmen, für das Sie arbeiten, konzentriert sich nicht auf etwas Bestimmtes, wie z. B. Scrum, das (Ziele) erzwingt ... ihr Ziel ist opportunistisch und basiert wahrscheinlich nur auf dem Umsatz, also ziehen sie die Entwickler dorthin, wo sie Geschäftsergebnisse erzielen müssen ... Scrum ist es nicht für diese Situationen gedacht, fürchte ich.

Sie sagen es ... sie kümmern sich um den WIP und das ist eine Kanban-Sache. Und sie sehen vielleicht, dass etwas gebraucht wird, weil sie schon lange nichts mehr davon gehört haben … also wieder Kanban!

Stoppen Sie Scrum und wechseln Sie zu Kanban ... das Leben aller wird einfacher.