Haben Sie es Ihrer Erfahrung nach als vorteilhaft empfunden, einem Product Owner die Änderungskontrolle aufzuzwingen, nachdem das Product Backlog vereinbart wurde?
IE Wenn er/sie den Umfang ändern möchte, indem er/sie das Backlog hinzufügt/herausnimmt/neu priorisiert, muss der PO einen formalen Änderungsantrag/IOCA einreichen, bevor er/sie eine genehmigte Änderung an den Scrum Master zur Planungsüberlegung weiterleitet.
Wenn er/sie den Umfang ändern möchte, indem er/sie das Backlog hinzufügt/herausnimmt/neu priorisiert, muss der PO einen formalen Änderungsantrag/IOCA einreichen, bevor er/sie eine genehmigte Änderung an den Scrum Master zur Planungsüberlegung weiterleitet.
Das ist das Gegenteil von Agilität. Während Scrum in Umgebungen, die eine formelle Änderungskontrolle erfordern, gut funktioniert, soll der Änderungskontrollprozess im Allgemeinen die Integrität der Produktionsumgebung schützen, anstatt das Product Backlog sakrosankt zu halten.
Ich vermute, dass die Anforderung der „Änderungssteuerung“ in Wirklichkeit ein Versuch der Beteiligten oder des Lenkungsausschusses ist, den Umfang oder das Budget des Projekts zu kontrollieren. Wenn dies der Fall ist, muss der Scrum Master die Organisation besser darüber aufklären, wie die iterative Entwicklung tatsächlich funktioniert, und mit dem Team zusammenarbeiten, um sicherzustellen, dass das Produkt am Ende jeder Iteration immer in einem veröffentlichungsfähigen Zustand ist.
Die Stakeholder können über den Product Owner jederzeit Elemente zum Product Backlog hinzufügen oder daraus entfernen . Das Einzige, was sie nicht tun können, ist, die Stories innerhalb des aktuellen Sprints zu ändern, es sei denn, der Product Owner fordert eine vorzeitige Beendigung und eine Rückkehr zum Sprint-Planning.
Technisch gesehen gibt es in Scrum nichts, was Stakeholder dazu auffordert oder daran hindert, die Änderungskontrolle für die Anforderungen durchzusetzen, die sie an den Product Owner weitergeben. Wie der Product Owner mit Stakeholdern interagiert, ist eine externe Eigenschaft des Scrum-Frameworks, das einfach vorschreibt, dass der Product Owner für den Inhalt und die Anordnung des Product Backlog verantwortlich ist.
Solch schweres Quarterbacking ist jedoch ein signifikanter „Projektgeruch“, der normalerweise darauf hinweist, dass die Organisation das iterative Entwicklungsmodell nicht angenommen hat und wahrscheinlich nicht versteht, wie die integrierten Prozesskontrollen des Frameworks effektiv genutzt werden können. Die Organisation über das Scrum-Framework aufzuklären, ist die Aufgabe des Scrum Masters, und das effektive Management der Stakeholder ist die Aufgabe des Product Owners.
Bildung scheint hier die fehlende Zutat zu sein. Natürlich ist Scrum auch keine Wunderwaffe, nicht für jede Organisation geeignet und möglicherweise einfach nicht für eine Command-and-Control-Organisation geeignet. Ein guter Wasserfall scheitert genauso wenig wie ein falsch implementiertes Scrum, daher kann es sich auch lohnen, zu überdenken, ob Scrum das richtige Framework für die Organisation ist.
Andere Rahmen können besser passen. Ihr Kilometerstand kann sicherlich variieren!
Ich habe das noch nie gemacht und es wäre ein großes Anti-Pattern, weil:
Allerdings ist dies viele Male passiert. Am Ende muss es um die Relevanz des Sprint-Ziels für das Business gehen. Wenn der PO etwas Relevantes für das Ziel hat, ermutige ich das Team, schnell zu entscheiden, welche Änderungen vorgenommen werden sollen, ohne die Geschwindigkeit zu erhöhen. Wenn es irrelevant ist, lasse ich den PO entscheiden, ob wir den Sprint stoppen und einen neuen Sprint starten sollen. 100 % der Zeit, in der der PO das Stoppen und Starten eines neuen Sprints versteht, ist weitaus teurer als das Hinzufügen einiger „dringender Änderungen“.
Schließlich ist es nicht ungewöhnlich, dass Teams auf traditionelle Weise arbeiten (BDUF, Waterfall usw.), während sie bestimmte agile Praktiken wie Rollen, Daily Scrums und Sprints anwenden. Das ist kein Scrum, aber immer noch besser als keine Intervalle zum „Inspizieren und Anpassen“. Ich vermute, dass dies auf Sie zutreffen könnte, daher kann es notwendig sein, Änderungsbarrieren zu schaffen, um das Projekt voranzubringen und im Rahmen zu halten.
Venture2099
Venture2099
Bernhard