La guía oficial de Scrum especifica las responsabilidades del Product Owner de la siguiente manera:
El Product Owner es responsable de maximizar el valor del producto resultante del trabajo del equipo de Scrum. La forma en que esto se hace esto puede variar ampliamente entre organizaciones, equipos Scrum e individuos.
El Product Owner también es responsable de la gestión eficaz de la pila del producto (Product Backlog), que incluye:
● Desarrollar y comunicar explícitamente el Objetivo del Producto;
● Creación y comunicación clara de elementos de trabajo pendiente del producto;
● Pedido de artículos de trabajo pendiente del producto;
● Asegurarse de que el trabajo pendiente del producto sea transparente, visible y comprendido.
Sin embargo, al ser Scrum un marco de trabajo y no una metodología, no explica en la guía cómo los Product Owners pueden hacer estas responsabilidades de manera eficiente, más allá de habilitar los eventos de Scrum y cumplir con sus artefactos. Y es que así como no hay una guía completa para la vida, tampoco para ser Product Owner.
En mi opinión, la guía de Scrum es una invitación a la experimentación, al desaprendizaje y al aprendizaje de otras fuentes.
Hasta que vivimos algo es hasta que podemos absorberlo bien y porque al ser Scrum una propuesta para trabajar a como hemos estado acostumbrados en muchas décadas de métodología tradicional, tenemos que habilitar la cultura de experimentación. Se trata de habilitar la agilidad basándonos en la validación de hipótesis con experimentos breves y medibles que nos ayuden a aumentar el nivel de confianza.
Algo vital de la cultura de experimentación es cultivar la curiosidad y hablando de los Product Owners, esta es una característica muy importante para:
Con el paso del tiempo y la mala combinación con la prisa, llegamos a normalizar prácticas ineficientes. Los problemas frecuentes no deberían de ser los mismos durante años. Aparte de prácticas ineficientes, también existe el conocimiento obsoleto. El conocimiento tiene valor en una empresa cuando lo podemos aplicar y nos lleva a resultados de éxito. Las prácticas ineficientes a veces están escritas en políticas y reglas que alguna vez tuvieron que existir debido a ciertas condiciones, pero un día, desaparecen las condiciones y las políticas se quedan solo estorbando y burocratizando.
Como Product Owners es importante quitar las barreras que impidan concebir productos geniales, dentro de esas barreras, hay algunas (lamentablemente) muy frecuentes, por ejemplo, los criterios de decisión. Estos se basan en jerarquía en la empresa y no en beneficios para los usuarios.
No existen criterios de priorización así que todo urge, por lo que todo tiene la misma importancia y termina atendiéndose igual que si no urgiera, solo que tiende a atenderse mal porque los equipos que trabajan con el síndrome de “todo urge”, viven con sobre carga y la sobre carga es una de las enemigas principales de la productividad y la calidad.
Una vez que desaprendemos, es decir, identificamos conocimientos obsoletos y prácticas ineficientes que hemos normalizados, abrimos la posibilidad para adquirir nuevos conocimientos. Los Product Owners son parte de varios mundos: El del Análisis de Negocio, el de la Experiencia de Usuario, el de Marketing y el del Negocio. Ser parte de esta intersección es muy enriquecedor cuando se sabe aprovechar, de lo contrario se termina perdido entre tantos conceptos y terminamos perdiendo a los miembros del equipo también.
Los conceptos que más recomiendo aprender para los Product Owners que empiezan en este camino son los siguientes:
El hecho de que la guía oficial de Scrum tenga pocas páginas, no significa que exija poco, solo que no puede ser una guía predictiva, ya que iría en contra de los principios de la agilidad y al final de cuentas, la responsabilidad de evaluarnos para estar concientes sobre la brecha de conocimiento tenemos para poder llevar nuestras funciones con eficiencia, es totalmente nuestra. Y como toda la teoría sin práctica no es nada, te dejo la invitación al nuevo Curso Práctico de Product Owner, el cual es una continuación del Curso de Fundamentos de Product Owner en el que pondremos tus conocimientos a prueba.
¡Nunca pares de aprender y transmitir lo que aprendes!
Leyendo el post, he recordado como inicie siendo Product Owner:
En la empresa en la que actualmente me encuentro laborando, hace más de un año inició con el cambio de metodología SAFe, cambio en el cual tuve la oportunidad y reto de ser la Product Owner en el equipo, y aunque me he preparado, leído y estudiado; efectivamente no hay un manual para ser PO. Al ser la pionera en la empresa con éste Rol me he topado con miles de obstáculos y problemas habidos y por haber, los cuales al no tener la guía de que hacer, me era difícil tomar decisiones, molestaba mucho al Product Manager para cualquier duda que tenía frente a un proceso. Hoy en día con las experiencias vividas y el aprendizaje continuo, no solo del rol, sino de la experiencia de compartir con diferentes clientes y proyectos, el síndrome de “todo urge” es difícil de desaparecerlo, pero mientras se tengan los “check” o llamados “criterios de priorización” para determinar si efectivamente algo es urgente e importante o solo es importante o solo es urgente por el proceso que tenga el cliente/usuario en ese momento, es posible tener una planificación sana, priorizando en base a los objetivos que ya tiene un valor de negocio y dedicar el esfuerzo en productividad y calidad.
Me gustó tu post y ya me apunté al curso . 😃
Que bonito post! Nos vemos en los comentarios del curso!
Excelente reflexión que dentro del marco ágil, el rol del product owner es de priorizar objetivos del negocio rentables. Pero lo PO siempre deben practicar el flujo de experimentar, desaprender, aprender; porque nada esta escrito en piedra en un marco ágil.