Anti Patrones del Product Owner

Anti Patrones del Product Owner

  1. Un Product Owner que no transmite la visión del Producto al equipo de desarrollo, solamente le entrega historias de usuario a desarrollar, convirtiendo a los Desarrolladores en tomadores de pedidos. Esto no fomenta la transparencia lo cual hace más difícil crear el Sprint Goal y darles un propósito.
  2. Un Product Owner que ordena a los Desarrolladores lo que tienen que desarrollar en cada Sprint y que además les impone el Sprint Goal atentando contra la autoorganización.
  3. Un Product Owner que cancela el “Sprint Review” para evitar que la organización no conozca lo que no se ha terminado o realiza un “Sprint Demo” con un incremento que no está completamente terminado. Este Product Owner evita que el progreso del incremento del producto sea transparente.
  4. Un Product Owner que no involucra a los Desarrolladores en el refinamiento del Product Backlog durante el Sprint. Este tipo de comportamiento hace que el Product Backlog no sea transparente e ignora el punto de vista que pueden aportar los Desarrolladores.
  5. Un Product Owner que no favorece la calidad del producto debido a que no participa de la definición de los criterios de terminado dejando que el equipo los defina. Este Product Owner luego exige que el equipo cumpla con entregar los Product Backlog Itens comprometidos durante el Sprint Planning aun cuando eso significa sacrificar calidad y no usar los criterios de terminado. Este escenario puede generar deuda técnica que reduce la entrega de valor.
  6. Un Product Owner que participa del Daily Scrum para controlar las tareas que han hecho y tienen que hacer los Desarrolladores. Esto lleva a limitar la creatividad, reducir el foco hacia el Sprint Goal y la entrega de valor, evitando además promover soluciones a los impedimentos.
  7. Un Product Owner que cree que su mayor responsabilidad es registrar en alguna herramienta las historias de usuario y los criterios de aceptación para luego entregar la documentación y el alcance definido a los Desarrolladores para que lo implementen. El peligro es la pérdida del trabajo en equipo para elaborar el Product Backlog, también se puede perder la visión del producto, contacto con el mercado, clientes y el contexto de negocio que ayuda a la inspección y adaptación para mejorar la entrega de valor en Scrum.

¡Compártelo con tus amigos!

Share on facebook
Share on twitter
Share on whatsapp
Share on telegram