Qué hacer con un PO que gestiona, dirige y controla el equipo

Soy ScrumMaster para un equipo de 7 devs/qa's.

Estoy luchando para asesorar a mi PO / comunicarme con mi PO. Por un lado, está muy interesado en ser un PO y trabajar de la forma en que lo hace, pero realmente no entiende que sus comportamientos no están ayudando al equipo a ser más autónomo y autogestionado.

Estos son los comportamientos que creo que están perjudicando al equipo:

  • Interrupciones implacables durante el día. Es un tipo muy extrovertido, encantador y extrovertido, pero todo el día se acerca a los desarrolladores solo para decir cómo les está yendo. Todo es muy positivo, pero muy perturbador.
  • Implacable pidiendo actualizaciones. ¿Cuándo terminará esto, cuándo terminará esto?
  • Unirse a los stand-up y siempre hablar durante los stand-up, siempre contribuir
  • Involucrarse en todas las facetas del equipo, desde los traspasos cuando los miembros del equipo se van, el diseño de la solución, el enfoque de control de calidad, lo que sea
  • No escribe criterios de aceptación, cuando la gente pide requisitos, dice que no se preocupe por los requisitos. QA pide requisitos, pero dice que no se preocupe. Los requisitos están en su cabeza y le gusta verbalizarlos, no capturarlos en jira.
  • Dirigir el equipo, gestionar el equipo, microgestionar el equipo
  • Se vuelve muy agresivo si no se le permite hacer esto.

En mi carrera, diría que es el que más se aleja de ser un Gerente de Producto y más como un gerente de comando y control.

Lo que he intentado: + 1 a 1, explicando el rol y el entrenamiento + Usar retrospectivas que hacen que el equipo llame la atención sobre la falta de criterios de aceptación + Talleres para que el equipo y el PO entiendan el PO, el SM y los roles del equipo.

Nada parece funcionar

¿Cómo reacciona la OP a estos diversos intentos de ayudarlos a mejorar?
¿Ha hablado con él gente del Equipo de Desarrollo para explicarle que las interrupciones no ayudan con el trabajo o que la falta de requisitos y criterios de aceptación dificultan el diseño, el desarrollo y las pruebas?
¿Le has dicho en el acto cuando hace algo que se supone que no debe hacer? Por ejemplo, ¿lo ha interrumpido en los encuentros diarios y le ha explicado que esta es una reunión para el equipo y que él es un invitado silencioso?
Ha hecho algunos intentos de observar en stand-ups, pero luego se mantiene en silencio hasta el final de la stand-up y luego dice que ahora es mi turno de hablar y pide actualizaciones, dirige a las personas para el día, etc., esencialmente tiene una reunión diaria tradicional después el stand up El equipo de desarrollo es bastante pasivo con él, no hables solo en retro sobre los criterios de aceptación o vendrán a mí. Lo he cortado, pero en general su opinión es que el equipo no entrega lo suficientemente rápido y no se autogestiona, por lo que tiene que intervenir para que las cosas avancen. Les he explicado que no pueden crecer así.
Cuando dirige a la gente para el día, ¿trata de cambiar lo que se decidió unos minutos antes? Porque después de que termine el standup diario, todos ya deberían tener un día completo planeado.

Respuestas (3)

Aquí hay algunas sugerencias.

Usar retrospectivas que hacen que el equipo llame la atención sobre la falta de criterios de aceptación

Los comportamientos que ha mencionado son todos temas válidos para retrospectivas, no solo la falta de criterios de aceptación.

Además, la idea de las retrospectivas no es solo plantear problemas, sino también monitorear el progreso hacia su resolución. Si el equipo elimina acciones de una retrospectiva, a menudo es una buena idea revisarlas en la próxima retrospectiva. De esta manera, se hace evidente si no se está progresando.

Lo que he probado: + 1 a 1, explicando el rol y formando

No solo entrene al propietario del producto, también busque entrenar al equipo. Enséñeles que está bien presionar al propietario del producto y plantear sus inquietudes en las retrospectivas. No es responsabilidad del Scrum Master resolver todos los problemas del equipo, pero es el rol del Scrum Master facilitar la resolución.

Es probable que esta situación solo se resuelva con todo el equipo trabajando juntos.

Implacable pidiendo actualizaciones. ¿Cuándo terminará esto, cuándo terminará esto?

Este comportamiento y otros mencionados tienen un impacto en el rendimiento y la eficacia del equipo. Repórtalo como parte de tus Sprint Reviews. Por ejemplo:

En Sprint 7 entregamos mucho valor, pero nuestra efectividad se vio reducida por las constantes interrupciones del equipo. Es probable que la producción del equipo aumente si pudiéramos mejorar esta situación.

Mantenga un tono positivo y enfatice que solo quiere mejorar el rendimiento del equipo.

Como persona extrovertida y extrovertida, puedo simpatizar con este enfoque. Puede ser impopular, pero también depende de los introvertidos ser más fuertes. Si quieres tiempo a solas dilo. Habla físicamente y di "ahora no". Le dejé claro a mi equipo que me dijera que me fuera. Todo el mundo es un adulto; pueden manejarlo.

Tengo dos comentarios:

  • Aborde uno o dos problemas a la vez (sea incremental) . ¡Esto requerirá todo su poder de negociación! Te sugiero que crees una lista de prioridades ordenada en lo que crees que será más fácil para él dejarlo ir y abordar cada lista una o dos cada vez. Empezaría por lo que le resulte más fácil, porque en cuanto demuestres tu punto, crearás confianza y podrá ceder en otras cosas más difíciles.

  • Lo que he intentado: + 1 a 1, explicando el rol y el entrenamiento + Usar retrospectivas que hacen que el equipo llame la atención sobre la falta de criterios de aceptación + Talleres para que el equipo y el PO entiendan el PO, el SM y los roles del equipo.

Aquí solo está explorando por qué usted y su equipo piensan que lo que está haciendo está "mal". También debe preguntarle y comprender profundamente por qué cree que lo que está haciendo es valioso para el equipo (¿quizás combinarlo con uno?).

Sugerencia: elija las disfunciones que el Equipo de Desarrollo considere no negociables, por ejemplo, personalmente elegiría interrumpir el Daily Scrum e interrumpir a los Desarrolladores durante la jornada laboral. Luego se dispuso a hacerlos cumplir con firmeza, asegurando al mismo tiempo la dignidad de todos. Pero hágalo muy transparente, por ejemplo, cambie el lugar del Daily Scrum, obtenga una cinta de 'POLICE DO NOT CROSS' y elimine 'LICE', etc. Hágalo divertido para todos.

Tenga en cuenta que estos son impedimentos. El papel de la administración en Agile es eliminar los impedimentos, así que asegúrese de contar con su apoyo. El comportamiento agresivo es completamente inaceptable y debe buscar ayuda específica al respecto.

Pero también vienen de un lugar de entendimiento. ¿Por qué el PO se comporta de esta manera? Si la OP no disfruta de seguridad en su entorno, ¿puedes ayudar con sus impedimentos?

No estoy seguro de cómo reaccionaría el PO a su sugerencia de cinta (especialmente porque parece que no le gusta que le digan qué hacer), ¡pero seguro que es original!
@Balala: sí, sugiero precaución y puede que no sea apropiado conocer a la persona/organización en cuestión (¡lo cual no sé!). Sin embargo, no querer hablar porque podría ofender o enojar a alguien es claramente un problema para este equipo y una acción radical pero divertida podría ser un rompehielos.
Qué hacer con un PO que gestiona, dirige y controla el equipo
RespuestasAquíPolítica de privacidad1y, 0v