Equipo Scrum y Product Owner trabajando uno contra el otro

Mi proyecto actual involucra a dos empresas. El propietario del producto de la empresa A y el equipo de desarrollo de la empresa B.

Recientemente, las dos empresas llegaron a un desacuerdo con respecto al propietario del producto (PO) por las siguientes razones:

  1. No da criterios de aceptación. Ella dará frases ingeniosas y los desarrolladores tienen que descubrir qué es lo que quiere. Si han terminado de refinar, se lo presentan al PO y ella puede aceptar o rechazar la historia. Si acepta, podemos llevarlo a la cartera de pedidos para un sprint.

  2. Ella no prioriza. El equipo de desarrollo necesita hacer esto. Si el Equipo prioriza, se queja de que estamos forzando las prioridades y si le preguntamos, dice 'tú decides'.

  3. Es muy grosera y tiene una personalidad explosiva si no está de acuerdo con el Equipo.

  4. Ella es una persona "especie de Scrum". Le gusta Scrum cuando le conviene. De lo contrario, se queja de Scrum, incluso después del entrenamiento.

  5. Ella es PO, analista de negocios y evaluadora (aprobación final)

La empresa A y B llegaron a un desacuerdo porque la empresa A afirma que no hace nada malo mientras que mi empresa, la empresa B, ve el cuello de botella que está causando. Es como un efecto dominó.

  1. Sin criterios de aceptación detallados = Más reuniones y tiempo dedicado a descubrir historias. Tengo que registrar historias, obtener prioridades y tener una reunión para descifrar sus frases ingeniosas.

  2. Rudeza = Baja la moral del equipo

  3. Múltiples roles = Uno de los roles se descuida dependiendo de lo que se requiera.

Ella ha sido la razón por la que no completamos el Sprint Goal en algunos de nuestros Sprints.

Esto se ha elevado al nivel de CEO de ambas compañías y los cambios que hicieron fueron:

  1. Moverla fuera de la oficina para que la rudeza y la explosividad no afecten al equipo.

Eso es todo.

He hecho numerosas sugerencias (como Scrum Master), creo que cuatro veces, en el último año, pero cayó en saco roto.

¿Tiene alguna sugerencia sobre un enfoque a seguir?

Suena como un problema político más que un problema de gestión de proyectos.
La alta dirección es dueña del problema. Si rompen la implementación de Scrum, pueden quedarse con ambas mitades.
Por mucho que pueda apreciar su posición, porque personalmente he estado en una situación similar, me pregunto si esta pregunta es una diatriba disfrazada de pregunta .
Una edición anterior intercambió la empresa A y B en el párrafo central, lo que hizo que el fondo fuera un poco confuso. Hice una edición para cambiar eso de nuevo. Supongo que es el empleador de la PO quien afirma que ella no hace nada malo.

Respuestas (2)

No da criterios de aceptación.

Esto no es un problema si el propietario del producto está feliz de hablar sobre las historias con el equipo y aclarar cualquier detalle. El equipo puede incluso crear sus propios criterios de aceptación como resultado de las discusiones si lo encuentran útil.

Si el Product Owner no está dispuesto a pasar el tiempo necesario explicando las historias, entonces hay una discusión sobre el compromiso del tiempo y la productividad.

ella no prioriza

¿Alguna idea de por qué? Valdría la pena tener una conversación con el propietario del producto sobre su motivación para este comportamiento. ¿Será que no saben qué historias tienen prioridad? ¿O tal vez no se sienten lo suficientemente empoderados para tomar decisiones prioritarias?

Es muy grosera y tiene una personalidad explosiva.

Valdría la pena reunir a todo el equipo con el propietario del producto para discutir formas de trabajar y qué comportamiento es aceptable. Muchos equipos tendrán 'términos de compromiso' escritos que tratarán de cumplir.

Ella es la PO, BA y probadora

Si hay problemas que surgen de esta combinación de roles, entonces la retrospectiva suele ser el lugar donde surgirían y, con suerte, se mitigarían.

¿Tiene alguna sugerencia sobre un enfoque a seguir?

Es poco probable que la confrontación sea productiva ya que Scrum es, por diseño, un enfoque colaborativo. Mi sugerencia sería hablar tanto como sea posible con el propietario del producto para tratar de determinar su motivación y ver si hay formas de trabajar que se pueden encontrar para mejorar la situación.

La escalada a la gerencia es un enfoque arriesgado ya que, a menos que se reemplace al Product Owner, es probable que el resultado sea aún más tensión en el equipo.

  1. En curso: realiza un seguimiento de tu velocidad.
  2. Documente todos los obstáculos e ineficiencias, causados ​​por ella o no.
  3. Menciónelos en las Retrospectivas de Sprint, hablando en un lenguaje neutral, tratando de encontrar soluciones a los problemas, no a las personas.
  4. Si no se pueden encontrar (e implementar) soluciones, entonces debe hacer dos cosas: comenzar a trabajar estas ineficiencias en sus estimaciones. Y asegúrese de que aquellos capaces de eliminar estas ineficiencias (por ejemplo, el director general) sean conscientes de que esta es la razón del ritmo lento.

En este punto, debería suceder una de tres cosas, en orden descendente de resultado ideal:

  • Encuentras soluciones aceptables en la Retrospectiva y los problemas desaparecen.
  • Los problemas son eliminados a la fuerza por los de arriba y los problemas desaparecen.
  • Los problemas y sus efectos son aceptados por los de arriba. Continuarás desarrollándote lentamente, pero aquellos a cargo son al menos conscientes de la causa raíz y han elegido significativamente aceptar el costo.
Publiqué esto antes de leer meta.stackexchange.com/questions/335508/…
Equipo Scrum y Product Owner trabajando uno contra el otro
RespuestasAquíPolítica de privacidad1y, 0v