Führen eines Product Owners in einer noch nicht agilen Organisation

TL; DR

Es hört sich wirklich so an, als ob sowohl der Scrum Master als auch der Product Owner in die Geschwindigkeits- und Auslastungsfalle geraten sind. Den Kreislauf durchbrechen.

Analyse der Rolle des Product Owners

Der PO möchte wissen, wie viele Stunden Programmierer X in jedem Sprint zur Verfügung hat und was genau er damit machen wird.

Nicht seine Angelegenheit in einem Scrum-Shop. Er ist Teil des Scrum-Teams, aber nicht für die Story-Zuordnung oder Teamorganisation zuständig. Ein Scrum-Team organisiert sich selbst (wenn es gut funktioniert), also ist dies ein No-Go.

Er möchte, dass am Ende jedes Sprints Demonstrationen von Funktionen abgeschlossen werden[.]

Das ist legitim. Ein Sprint Review ist ein Standard-Scrum-Meeting und definitiv Teil des Frameworks. Es sollte sich auf abgeschlossene, für den Benutzer sichtbare Funktionen konzentrieren, aber das ist so etwas wie ein Implementierungsdetail. Das Entscheidende ist, dass das Sprint Review die Gelegenheit ist, dem Product Owner und den Stakeholdern zu zeigen, was während des letzten Sprints abgeschlossen wurde.

[I]Wenn eine Implementierung komplizierter ist als wir erwartet haben und etwas nicht getan wird, ist er der Ansicht, dass wir unsere Verpflichtung gebrochen haben.

Vielleicht und vielleicht auch nicht. Hier werden mehrere Probleme behandelt. Schauen wir sie uns an.

1. Das Team sollte eine "Definition of Done" haben. Wenn das Sprint-Ziel nicht erreicht wurde und die Arbeit nicht der Definition von erledigt entspricht, dann ist sie einfach nicht erledigt. Es ist nie teilweise fertig; In Scrum ist „fertig“ für eine User Story alles oder nichts.
2. Der Vorbehalt zum vorherigen Axiom ist, wenn das Team und der Product Owner „fertig“ im Laufe eines Sprints gemeinsam neu definieren. Wenn Sie sich mitten in einem Sprint befinden und feststellen, dass Sie das Sprint-Ziel nicht erreichen oder eine Story nicht abschließen werden, sollten Sie sofort den Product Owner einbeziehen, um Ihre Optionen zu besprechen.
3. Wenn das Team die Sprint-Planung ordnungsgemäß durchführt, verpflichtet sich das Team zum Sprint-Ziel und zu einer Reihe von User Stories. Deshalb ist es wichtig, richtig einzuschätzen und sich nicht zu überfordern.

Umgang mit fehlgeschlagenen oder fehlgeschlagenen Sprints

Die PO liegt jedoch falsch, wenn sie dies zu einem Schuldproblem macht. Die Aufgabe des Scrum Masters besteht darin, mithilfe des Scrum-Prozesses die Erwartungen aller während und nach einem gescheiterten Sprint zu managen.

Wenn ein Sprint zu scheitern droht, sollte der PO so schnell wie möglich einbezogen werden. Der Product Owner hat mehrere Möglichkeiten:

1. Arbeiten Sie mit dem Team zusammen, um das Sprint-Ziel oder die akzeptierten User Stories neu zu definieren, um den Wert des Sprints zu retten.
2. Beenden Sie den Sprint vorzeitig, damit eine Sprint-Retrospektive und eine neue Sprint-Planungssitzung den Prozess neu starten können, jetzt, wo jeder mehr Einblick hat.

Keine der Optionen sollte ein „Schuldspiel“ sein. Die Notwendigkeit, einen Sprint neu zu verhandeln oder neu zu starten, kommt in Scrum häufig vor, insbesondere bei Teams, die neu in der Schätzung sind. Es ist normalerweise das Ergebnis einiger oder aller der folgenden:

• Prozessbehinderungen, die nicht vorhergesehen oder in den Story-Schätzungen enthalten waren.
• Falsche Schätzungen einer oder mehrerer User Stories.
• Ein zu ehrgeiziges Sprint-Ziel.
• Übermäßiges Commitment während der Sprint-Planung aufgrund falscher Story-Schätzungen, Überschätzung der Teamgeschwindigkeit, des Anti-Patterns „100 % Auslastung“ , Zuweisung von Stories an das Team (anstatt dass das Team seine eigenen Commitments eingeht) oder aus anderen Gründen fügt mehr Storys in das Sprint Backlog ein, als vernünftigerweise in einem einzigen Sprint abgeschlossen werden können.

Nutzung Anti-Pattern

Das Anti-Pattern mit 100% Auslastung macht mir am meisten Sorgen. Sie sagen, dass der Product Owner Dinge sagt wie:

OK, wir haben 40 Arbeitsstunden für Arthur und 32 Arbeitsstunden für Candace, und da sie beide halbtags an diesem Projekt arbeiten sollen, sollten sie diese Arbeit bis zum Ende des nächsten Sprints abschließen.

Das ist ein doppelter Irrtum. Erstens ist es dem Product Owner nicht gestattet , den Arbeitsaufwand für das Team zu schätzen. Seine Rolle besteht darin, Storys zu priorisieren und mit dem Rest des Scrum-Teams zusammenzuarbeiten, um den Umfang oder die Liefertermine anzupassen, um die Geschäftsanforderungen zu erfüllen, basierend auf den Schätzungen des Teams zum Arbeitsaufwand.

Zweitens organisiert sich ein erfolgreiches Scrum-Team selbst. Wenn der Product Owner Arbeit zuweist, versucht, eine Auslastung von 100 % pro Person zu implementieren, oder anderweitig die Intra-Sprint-Prozesse des Teams mikroverwaltet, dann muss der Scrum Master:

1. Informieren Sie den Product Owner über die Vorteile (und Einschränkungen) des Prozesses.
2. Stellen Sie sicher, dass sich das Team nicht zu sehr verpflichtet.
3. Coachen Sie das Team, um sich so effizient wie möglich um akzeptierte Sprintziele zu organisieren. Das hat nichts mit Verwertung zu tun, sondern alles mit Miteigentum und Selbstverpflichtung .

Das Ziel von Scrum besteht nicht darin, die Funktionsgeschwindigkeit oder Ressourcennutzung zu maximieren; Das Ziel von Scrum ist es, den Cone of Uncertainty in großen oder komplexen Projekten zu managen und ein nachhaltiges Arbeitstempo auf der Grundlage immer zuverlässigerer Story-Schätzungen zu schaffen. Mit anderen Worten, Zuverlässigkeit und Konsistenz sind Trumpf. Die Geschwindigkeit entwickelt sich, wenn sich Prozesse, Schätzungsverfahren, Automatisierung und Arbeitsabläufe im Laufe der Zeit verbessern.

Geht der PO in einer wirklich agilen Umgebung so weit, Dinge zu sagen wie: „Okay, wir haben 40 Arbeitsstunden für Arthur und 32 Arbeitsstunden für Candace, und da sie jeweils die Hälfte sein sollen – Zeit für dieses Projekt, sie sollten diese Arbeit bis zum Ende des nächsten Sprints abschließen." ??

Nun, in einer Scrum-Umgebung oder in anderen Projektumgebungen sollte der Product Owner die Aufgaben für die Entwickler nicht schätzen. Personen, die die Arbeit erledigen, sollten Schätzungen abgeben, insbesondere wenn sie Geschichten in Aufgaben zerlegen. Dies ist sogar noch wichtiger in Scrum, wo das Team selbst organisiert ist.

Außerdem haben Sie, da Sie gerade erst anfangen, wahrscheinlich die Team-Velocity (wie viele Storys das Team in einer Iteration implementieren kann) nicht im Griff, was die Aussage des Product Owners noch lächerlicher macht.

In meiner Gruppe sind die Product Owner dafür verantwortlich, was wir tun werden, und die Teams sind dafür verantwortlich, wie es getan wird.

Es ist völlig in Ordnung, wenn der Product Owner eine Meinung teilt, aber man sollte Schätzungen nicht mit Zielen verwechseln.

Es könnte der richtige Zeitpunkt für Ihre Gruppe sein, die 10 tödlichen Fehler der Softwareentwicklung zu wiederholen . :-)

Rollenbeschreibungen ... oder deren Fehlen. Schlecht formulierte Rollenbeschreibungen werden Ihre Fähigkeiten verheerend beeinträchtigen.

Ob dieser PO mit der Fokussierung auf Stunden außerhalb seiner Grenzen liegt, hängt wirklich davon ab, wie Ihre Organisation die Rolle definiert. Ich wette, Sie könnten ein paar widersprüchliche Meinungen bekommen, wenn Sie diese Seite begutachten. Aber am Ende des Tages wird es so, wie Ihre Organisation die Grenzen jeder Rolle definiert.

Apropos Grenzen, das wird beim Verfassen von Rollenbeschreibungen oft übersehen. Die meisten schreiben einfach an Zuständigkeiten. Sie vergessen Verantwortlichkeiten und Grenzen.

Da Sie sich beschweren, klingt es so, als würde der PO Ihre Wahrnehmung der Grenze zwischen seiner Rolle und der Rolle des agilen Teamleiters überschreiten.

Ihre Antwort darauf, was in einem agilen Umfeld richtig ist, findet sich nicht; es wird durch die ordnungsgemäße Erstellung fester Rollenbeschreibungen für die Organisation gefunden.

Agiles gemeinsames Verständnis

Kurz gesagt, agile Methoden wie Scrum oder XP teilen die Verantwortlichkeiten normalerweise in drei Teile auf:

1. das funktionsübergreifende Team : alle Personen (Entwickler, Tester, Integratoren...), die für die eigentliche Projektarbeit benötigt werden. Sie sind in der Regel selbstorganisiert, was im Grunde bedeutet, dass es niemanden außerhalb des Teams gibt, der einzelnen Teammitgliedern Aufgaben zuweist . Sie verpflichten sich zu der Arbeit, die sie in jeder Iteration leisten können (für iterationszentrierte Methoden wie Scrum. Bei flussorientierten Teams wie in Kanban kann es etwas anders sein).

2. der Coach : In Scrum „Scrum Master“ genannt, ist er für den WIE-Teil verantwortlich. Er kennt die Methodik und wie man sie anwendet. Seine Arbeit besteht darin, sowohl dem Product Owner als auch dem Team bei der Zusammenarbeit zu helfen. Er ist kein Projektleiter im klassischen Verständnis und wird keine Arbeit zuweisen oder seine Entscheidungen aufzwingen .

3. der Product Owner : in XP "Kunde" genannt, ist er für den WAS-Teil verantwortlich. Der Product Owner ist der Vertreter der Stakeholder. Für das Team besteht seine Rolle darin , eine priorisierte Menge von Elementen bereitzustellen, an denen gearbeitet werden soll (Features, User Stories usw.). Für die Stakeholder ist es seine Aufgabe, den Projektfortschritt zu melden. Der Product Owner arbeitet in der Regel Vollzeit am Projekt und ist für das Team leicht verfügbar.

Wenn Sie also – ich meine Ihr Unternehmen, Ihr Team, Ihre PO usw. – sich ausdrücklich für eine solche Methode entschieden haben – dies aber nicht getan haben –, sollte es keinen Zweifel daran geben, was in der Verantwortung aller liegt. In diesem Fall sollte (müssen) sich der Product Owner überhaupt nicht mit dem WIE-Teil auseinandersetzen.

Die Rolle eines Scrum Masters ist hier wichtig, da er dafür sorgt, dass niemand die Grenze überschreitet. Für eine auf Scrum fokussierte Antwort sollten Sie auch die Frage „ Warum können der Scrum Master und der Projektmanager nicht dieselbe Person sein? “ lesen, die sehr interessante Antworten enthält.

Rollendefinition

mein 20-köpfiges Entwicklungsteam hat einen Product Owner gewonnen

Soweit ich Ihre Frage verstehe, wurde der Product Owner in Ihr Team deus ex machina gesteckt . Wenn ich das richtig verstanden habe, könnte es ein Missverständnis in der Rollendefinition geben, das Sie versuchen müssen zu klären. Die Antwort von David Espina ist hier in diesem Punkt ziemlich klar. "Product Owner" ist schließlich nur ein Name...

Klassischer Projektmanager

Der PO möchte wissen, wie viele Stunden Programmierer X in jedem Sprint zur Verfügung hat und was genau er damit machen wird.

Wenn Ihr PO früher ein Command-and-Control-Projektmanager war, hat er möglicherweise Probleme damit, „nur“ ein PO zu werden. Er ist daran gewöhnt, viele Metriken in Bezug auf einzelne Arbeiten zu haben, die es ihm ermöglichen, den Fortschritt des Projekts zu überwachen. Versuchen Sie zu verstehen, warum er diese Daten sammeln möchte und wie Sie ihm relevante Indikatoren zur Verfügung stellen könnten, die dieselbe Rolle erfüllen würden, aber auf einem höheren Niveau (Geschwindigkeit, Durchsatz, Zykluszeit usw.).

Er möchte vielleicht auch sicherstellen, dass jeder zu 100 % ausgelastet ist. Bitte beachten Sie die Antwort von CodeGnome zu diesem Punkt. Lesen Sie auch Pawel Brodzinskis Artikel A Myth of 100% Utilization .

Vertrauen

„OK, wir haben 40 Arbeitsstunden für Arthur und 32 Arbeitsstunden für Candace, und da sie beide halbtags an diesem Projekt arbeiten sollen, sollten sie diese Arbeit bis zum Ende des nächsten Sprints abschließen. "

Wenn Ihr Product Owner oft auf diese Ebene gehen möchte, besteht möglicherweise ein Vertrauensproblem zwischen ihm und Ihnen. Vielleicht lässt ihn Ihr Mangel an Erfahrung mit agilen Projekten, seine Erfahrung mit nicht-agilen Projekten oder eine mögliche gebrochene Zusage früher im Projekt zögern, Ihnen und Ihrem Team zu vertrauen. Unter geschäftlichem Druck möchte er es vielleicht „selbst machen“.

In dieser Situation möchten Sie die Dinge schnell klären, da dieser Mangel an Vertrauen wahrscheinlich Ihr Projekt töten wird.

Zusammenfassung

Ist meine obige Aussage zur Rolle der PO legitim?

Absolut: ja. Ihre Definition eines Product Owners ist sehr „scrumy“. Aber die Sache ist die, dass es offensichtlich irgendwo ein Missverständnis gibt, entweder über die Rolle des anderen oder über die Fähigkeiten des anderen oder über das Ziel des anderen usw. Stellen Sie sicher, dass Sie beide in dieser Frage auf der gleichen Seite stehen.