Inspirado en la estructura liberadora TRIZ. Ser un buen Product Owner es un desafío que puede iniciar entendiendo su rol como promotor de la transparencia y del trabajo en equipo respetando los límites de la autoorganización.
- Un Product Owner que no transmite la visión del Producto al equipo de desarrollo, solamente le entrega historias de usuario a desarrollar, convirtiendo al equipo de desarrollo en tomadores de pedidos. Esto no fomenta la transparencia lo cual hace más difícil crear el Sprint Goal y darle un propósito al equipo de desarrollo.
- Un Product Owner que ordena al equipo lo que tiene que desarrollar en cada Sprint y que además les impone el Sprint Goal atentando contra la autoorganización del equipo de desarrollo.
- 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.
- Un Product Owner que no involucra al equipo de desarrollo 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 puede aportar el equipo de desarrollo.
- 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.
- Un Product Owner que participa del Daily Scrum para controlar las tareas que han hecho y tienen que hacer los miembros del equipo de desarrollo. Esto lleva a limitar la creatividad del equipo, reduce el foco hacia el Sprint Goal y la entrega de valor, evitando además que el equipo promueva soluciones a los impedimentos. SI el Product Owner participa de este evento debe ayudar a mejorar la autoorganización del equipo de desarrollo.
- 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 al equipo para que la implemente. 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.
Les comparto el enlace donde pueden adquirir mi libro Notas de Scrum Profesional: https://www.amazon.com/dp/B082S26DLH
Pueden ver la siguiente programación de los cursos oficiales que brindo en:
https://www.discoveryfast.com/certificaciones
Me pueden contactar en jfrancia@discoveryfast.com