Scrum Team und Product Owner arbeiten gegeneinander

Mein aktuelles Projekt umfasst zwei Unternehmen. Der Product Owner von Unternehmen A und das Entwicklungsteam von Unternehmen B.

Kürzlich kam es aus folgenden Gründen zu einer Meinungsverschiedenheit zwischen den beiden Unternehmen bezüglich des Product Owners (PO):

  1. Annahmekriterien nennt sie nicht. Sie wird Einzeiler geben und die Entwickler müssen herausfinden, was sie will. Wenn sie mit der Verfeinerung fertig sind, legen sie es der PO vor und sie kann die Geschichte annehmen oder ablehnen. Wenn sie akzeptiert, können wir es für einen Sprint in den Rückstand ziehen.

  2. Sie priorisiert nicht. Das Entwicklungsteam muss dies tun. Wenn das Team Prioritäten setzt, beschwert sie sich, dass wir Prioritäten erzwingen, und wenn wir sie fragen, sagt sie: „Sie können entscheiden“.

  3. Sie ist sehr unhöflich und hat eine explosive Persönlichkeit, wenn sie mit dem Team nicht einverstanden ist.

  4. Sie ist eine Art Scrum-Person. Sie mag Scrum, wenn es ihr passt. Ansonsten schimpft sie über Scrum, auch nach dem Coaching.

  5. Sie ist PO, Business Analyst und Tester (Endabnahme)

Unternehmen A und B kamen zu Meinungsverschiedenheiten, weil Unternehmen A angibt, nichts falsch zu machen, während mein Unternehmen, Unternehmen B, den Engpass sieht, den es verursacht. Es ist wie ein Welleneffekt.

  1. Keine detaillierten Akzeptanzkriterien = Mehr Meetings und Zeitaufwand für das Erfinden von Geschichten. Ich muss Geschichten protokollieren, Prioritäten setzen und ein Meeting haben, um ihre Einzeiler zu entschlüsseln.

  2. Unhöflichkeit = Senkt die Moral des Teams

  3. Mehrere Rollen = Je nach Bedarf wird eine der Rollen vernachlässigt.

Sie war der Grund dafür, dass wir das Sprintziel in einigen unserer Sprints nicht erreicht haben.

Dies wurde auf die CEO-Ebene beider Unternehmen angehoben, und die von ihnen vorgenommenen Änderungen waren:

  1. Bringen Sie sie aus dem Büro, damit die Unhöflichkeit und Explosivität das Team nicht beeinträchtigen.

Das ist alles.

Ich habe (als Scrum Master) zahlreiche Vorschläge gemacht, ich glaube viermal, im vergangenen Jahr, aber es ist auf taube Ohren gestoßen.

Haben Sie Vorschläge für eine Vorgehensweise?

Klingt eher nach einem Politikproblem als nach einem Projektmanagementproblem.
Die Geschäftsleitung hat das Problem. Wenn sie die Scrum-Implementierung brechen, dürfen sie beide Hälften behalten.
So sehr ich Ihre Position einschätzen kann, weil ich persönlich in einer ähnlichen Situation war, frage ich mich, ob diese Frage eine als Frage getarnte Tirade ist ?
Bei einer früheren Bearbeitung wurden die Unternehmen A und B im mittleren Absatz vertauscht, wodurch der Hintergrund etwas verwirrend wurde. Ich habe eine Bearbeitung vorgenommen, um das wieder zu ändern. Ich gehe davon aus, dass es der Arbeitgeber der PO ist, der erklärt, dass sie nichts falsch macht.

Antworten (2)

Annahmekriterien nennt sie nicht

Das ist kein Problem, wenn der Product Owner die Storys gerne mit dem Team durchspricht und Details klärt. Das Team kann als Ergebnis der Diskussionen sogar seine eigenen Akzeptanzkriterien erstellen, wenn es dies für nützlich hält.

Wenn der Product Owner nicht bereit ist, die nötige Zeit für das Erklären der Stories aufzuwenden, muss über Zeitaufwand und Produktivität diskutiert werden.

Sie priorisiert nicht

Irgendeine Idee warum? Es lohnt sich, mit dem Product Owner über seine Motivation für dieses Verhalten zu sprechen. Ist es, dass sie nicht wissen, welche Geschichten Priorität haben? Oder fühlen sie sich vielleicht nicht ausreichend ermächtigt, vorrangige Entscheidungen zu treffen?

Sie ist sehr unhöflich und hat eine explosive Persönlichkeit

Es lohnt sich, das gesamte Team mit dem Product Owner zusammenzubringen, um Arbeitsweisen und akzeptables Verhalten zu besprechen. Viele Teams haben schriftliche „Einsatzbedingungen“, an die sie sich zu halten versuchen.

Sie ist die PO, BA und Testerin

Wenn es Probleme gibt, die sich aus dieser Kombination von Rollen ergeben, dann ist die Retrospektive normalerweise der Ort, an dem sie auftauchen und hoffentlich gemildert werden.

Haben Sie Vorschläge für eine Vorgehensweise?

Es ist unwahrscheinlich, dass eine Konfrontation produktiv ist, da Scrum von Natur aus ein kollaborativer Ansatz ist. Mein Vorschlag wäre, so viel wie möglich mit dem Product Owner zu sprechen, um zu versuchen, seine Motivation zu ermitteln und zu sehen, ob es Möglichkeiten gibt, die Situation zu verbessern.

Die Eskalation an das Management ist ein riskanter Ansatz, denn wenn der Product Owner nicht ersetzt wird, wird das Ergebnis wahrscheinlich zu noch mehr Spannungen im Team führen.

  1. Fortlaufend - verfolgen Sie Ihre Geschwindigkeit.
  2. Dokumentieren Sie alle Hindernisse und Ineffizienzen, die von ihr oder anderweitig verursacht wurden.
  3. Bringen Sie sie in den Sprint-Retrospektiven zur Sprache, sprechen Sie in neutraler Sprache - versuchen Sie, Lösungen für Probleme zu finden, nicht für Menschen.
  4. Wenn keine Lösungen gefunden (und umgesetzt) ​​werden können, müssen Sie zwei Dinge tun: Fangen Sie an, diese Ineffizienzen in Ihre Schätzungen einzubeziehen. Und stellen Sie sicher, dass diejenigen, die in der Lage sind, diese Ineffizienzen zu beseitigen (z. B. der CEO), sich bewusst sind, dass dies der Grund für das langsame Tempo ist.

An diesem Punkt sollte eines von drei Dingen passieren, in absteigender Reihenfolge des idealen Ergebnisses:

  • In der Retrospektive finden Sie akzeptable Lösungen und die Probleme verschwinden.
  • Die Probleme werden von den Höheren zwangsweise beseitigt und die Probleme verschwinden.
  • Die Probleme und ihre Auswirkungen werden von den Höheren akzeptiert. Sie werden sich langsam weiterentwickeln, aber die Verantwortlichen sind sich zumindest der Grundursache bewusst und haben sich bewusst dafür entschieden, die Kosten zu akzeptieren.