Was tun mit einem PO, der das Team leitet, leitet und kontrolliert?

Ich bin ein ScrumMaster für ein Team von 7 Entwicklern/QAs.

Ich habe Mühe, meinen PO zu coachen / zu meinem PO durchzukommen. Einerseits ist er sehr daran interessiert, ein PO zu sein und so zu arbeiten, wie ein PO arbeitet, aber er versteht einfach nicht wirklich, dass sein Verhalten dem Team nicht hilft, autonomer und selbstverwaltender zu werden.

Dies sind die Verhaltensweisen, von denen ich glaube, dass sie dem Team schaden:

  • Unerbittliche Unterbrechungen während des Tages. Er ist ein sehr extrovertierter, liebenswürdiger, aufgeschlossener Typ, aber den ganzen Tag kommt er zu den Entwicklern, nur um zu sagen, wie geht es Ihnen, alles sehr positiv, aber sehr störend
  • Unermüdliches Nachfragen nach Updates. Wann wird das fertig sein, wann wird das fertig sein
  • Sich den Standups anschließen und während der Standups immer reden, sich immer einmischen
  • Sich in alle Facetten des Teams einbringen, von der Übergabe, wenn Teammitglieder das Team verlassen, über das Lösungsdesign bis hin zum QA-Ansatz, wie Sie es nennen
  • Schreibt keine Akzeptanzkriterien, wenn Leute nach Anforderungen fragen, sagt er, mach dir keine Sorgen über die Anforderungen. QAs fragen nach Anforderungen, aber er sagt, er solle sich keine Sorgen machen. Die Anforderungen sind in seinem Kopf und er verbalisiert sie gerne, anstatt sie in Jira festzuhalten.
  • Das Team leiten, das Team leiten, das Team im Mikromanagement führen
  • Er wird sehr aggressiv, wenn er das nicht darf

In meiner Karriere würde ich sagen, dass er am weitesten davon entfernt ist, ein Produktmanager zu sein, und eher ein Command-and-Control-Manager.

Was ich versucht habe: + 1-on-1's, Erklärung der Rolle und Coaching + Nutzung von Retrospektiven, die das Team dazu bringen, die fehlenden Akzeptanzkriterien zu benennen + Workshops, die Team und PO dazu bringen, die Rollen von PO, SM und Team zu verstehen.

Nichts scheint zu funktionieren

Wie reagiert die PO auf diese verschiedenen Versuche, ihnen dabei zu helfen, besser zu werden?
Haben Leute im Entwicklungsteam mit ihm gesprochen, um ihm zu erklären, dass die Unterbrechungen bei der Arbeit nicht helfen oder dass das Fehlen von Anforderungen und Akzeptanzkriterien das Design, die Entwicklung und das Testen erschweren?
Haben Sie ihm sofort gesagt, wenn er etwas tut, was er nicht tun soll? Haben Sie ihm zum Beispiel bei Daily Standups das Wort abgeschnitten und erklärt, dass dies ein Meeting für das Team ist und er ein stiller Gast ist?
Er hat einige Versuche unternommen, im Stand-Up zu beobachten, aber dann bleibt er bis zum Ende des Stand-Ups ruhig und sagt dann, dass ich jetzt an der Reihe bin, zu sprechen, und fragt nach Updates, weist die Leute für den Tag an usw., hat im Wesentlichen ein traditionelles tägliches Meeting danach der Aufstand. Das Entwicklerteam ist ihm gegenüber ziemlich passiv, spricht nicht einfach im Nachhinein über die Akzeptanzkriterien, oder sie kommen zu mir. Ich habe ihm das Wort abgeschnitten, aber im Allgemeinen ist er der Meinung, dass das Team nicht schnell genug liefert und sich nicht selbst verwaltet, also muss er eingreifen, um die Dinge in Gang zu bringen. Ich habe ihnen erklärt, dass sie so nicht wachsen können.
Wenn er die Leute für den Tag leitet, versucht er dann, das zu ändern , was nur wenige Minuten zuvor beschlossen wurde? Denn nach dem Daily Standup sollte jeder bereits einen vollen Tag durchgeplant haben.

Antworten (3)

Hier sind ein paar Vorschläge.

Verwendung von Rückblicken, die das Team veranlassen, die fehlenden Akzeptanzkriterien zu benennen

Die von Ihnen erwähnten Verhaltensweisen sind allesamt gültige Themen für Retrospektiven, nicht nur das Fehlen von Akzeptanzkriterien.

Außerdem besteht die Idee von Retrospektiven nicht nur darin, Probleme anzusprechen, sondern auch den Fortschritt bei ihrer Lösung zu überwachen. Wenn das Team aus einer Retrospektive Maßnahmen ergreift, ist es oft eine gute Idee, diese bei der nächsten Retrospektive zu überprüfen. So wird sichtbar, wenn keine Fortschritte erzielt werden.

Was ich ausprobiert habe: + 1-on-1's, Erklärung der Rolle und Coaching

Coachen Sie nicht nur den Product Owner, sondern auch das Team. Bringen Sie ihnen bei, dass es in Ordnung ist, den Product Owner zurückzudrängen und ihre Bedenken bei Retrospektiven zu äußern. Es liegt nicht in der Verantwortung des Scrum Masters, alle Probleme des Teams zu lösen, aber es ist die Rolle des Scrum Masters, die Lösung zu erleichtern .

Es ist wahrscheinlich, dass diese Situation nur gelöst werden kann, wenn das gesamte Team an einem Strang zieht.

Unermüdliches Nachfragen nach Updates. Wann wird das fertig sein, wann wird das fertig sein

Dieses und andere erwähnte Verhalten wirken sich auf die Leistung und Effektivität des Teams aus. Melde es als Teil deiner Sprint Reviews. Zum Beispiel:

In Sprint 7 haben wir viele gute Werte geliefert, aber unsere Effektivität wurde durch ständige Unterbrechungen des Teams verringert. Es ist wahrscheinlich, dass die Leistung des Teams gesteigert werden würde, wenn wir diese Situation verbessern könnten.

Halten Sie den Ton positiv und betonen Sie, dass Sie nur die Leistung des Teams verbessern wollen.

Als aufgeschlossener, extrovertierter Mensch kann ich mit dieser Herangehensweise sympathisieren. Es mag unbeliebt sein, aber es ist auch für Introvertierte, stärker zu sein. Wenn du Zeit für dich haben willst, sag es. Sprechen Sie sich körperlich aus und sagen Sie „nicht jetzt“. Ich habe meinem Team klar gemacht, dass es mir sagen soll, dass es gehen soll. Jeder ist ein Erwachsener; sie können damit umgehen.

Ich habe zwei Anmerkungen:

  • Behandeln Sie ein/zwei Probleme gleichzeitig (seien Sie inkrementell) . Das erfordert Ihre ganze Verhandlungsstärke! Ich schlage vor, dass Sie eine Priorisierungsliste erstellen, die Ihrer Meinung nach einfacher für ihn ist, loszulassen und jede Liste jedes Mal ein oder zwei anzusprechen. Ich würde damit beginnen, was für ihn einfacher ist, denn sobald Sie Ihren Standpunkt beweisen, schaffen Sie Vertrauen und er wird in der Lage sein, sich anderen schwierigeren Dingen zu stellen

  • Was ich versucht habe: + 1-on-1's, Erklärung der Rolle und Coaching + Nutzung von Retrospektiven, die das Team dazu bringen, die fehlenden Akzeptanzkriterien zu benennen + Workshops, die Team und PO dazu bringen, die Rollen von PO, SM und Team zu verstehen.

Hier untersuchen Sie nur, warum Sie und Ihr Team denken, dass das, was er tut, „falsch“ ist. Sie müssen ihn auch fragen und tief verstehen, warum er denkt , dass das, was er tut, für das Team wertvoll ist (vielleicht mit einem kombinieren?).

Vorschlag: Wählen Sie die Störungen aus, die das Entwicklungsteam für nicht verhandelbar hält, z. B. würde ich persönlich die Unterbrechung des Daily Scrum und die Unterbrechung der Entwickler während des Arbeitstages wählen. Machen Sie sich dann daran, sie konsequent durchzusetzen und gleichzeitig die Würde aller zu gewährleisten. Aber machen Sie es sehr transparent, z. B. ändern Sie den Ort des Daily Scrum, besorgen Sie sich ein 'POLICE DO NOT CROSS'-Band und löschen Sie 'LICE' usw. Machen Sie es allen Spaß.

Beachten Sie, dass dies Hindernisse sind. Die Rolle des Managements bei Agile besteht darin, Hindernisse zu beseitigen, also stellen Sie sicher, dass Sie ihre Unterstützung haben. Aggressives Verhalten ist völlig inakzeptabel und Sie sollten sich diesbezüglich gezielte Hilfe suchen.

Aber kommen auch von einem Ort des Verstehens. Warum verhält sich die PO so? Wenn der PO keine Sicherheit in seiner Umgebung genießt, können Sie ihm bei seinen Behinderungen helfen?

Ich bin mir nicht sicher, wie der PO auf Ihren Bandvorschlag reagieren würde (zumal er es anscheinend nicht mag, wenn man ihm sagt, was er tun soll), aber es ist auf jeden Fall originell!
@Balala: Ja, ich schlage Vorsicht vor und es ist möglicherweise überhaupt nicht angebracht, die betreffende Person / Organisation zu kennen (was ich nicht tue!). Sich nicht zu äußern, weil es Anstoß erregen oder jemanden wütend machen könnte, ist jedoch eindeutig ein Problem für dieses Team, und radikale, aber unterhaltsame Aktionen könnten ein Eisbrecher sein.