Product Owner ¿Qué hace?
Por Vanessa Amaya
He notado que conforme han pasado los años, ya va quedando claro qué es un Product Owner, lo que veo que sigue presente es la duda de qué debe de hacer, hasta dónde llegan sus responsabilidades y quién es la persona idónea para serlo.
Considero que esto ha pasado por los siguientes motivos:
El trabajo en silos que hay entre quienes tienen perfil de negocio y perfiles desarrolladores o creadores de la realidad los productos.
Que no solo implica “un rol nuevo en el equipo” sino quitar malas prácticas con respecto al dimensionamiento del trabajo y maneras en las que se comunica a los equipos ejecutores lo que se necesita crear.
La guía oficial de Scrum no profundiza (ni tiene por qué hacerlo) respecto al detalle e implicaciones del alcance del Product Owner.
La palabra Owner se ha distorsionado mucho y con frecuencia se toma como Poder y Arbitrariedad cuando en realidad necesita una connotación de alta responsabilidad y compromiso.
En este blog te hablaré del Iceberg del Product Owner:
Lo que se ve en la superficie de lo que dice LA GUÍA OFICIAL vs. LO QUE IMPLICA eso en la agilidad organizacional.
Definición
Lo que dice Guía:
“El Propietario del Producto 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.“
lo que implica:
La justificación de valor que busca la agilidad principalmente es el valor hacia el usuario o consumidor final y hablando del producto el valor es también hacia el negocio.
Esto implica que Product Owner necesita conocer para quién está trabajando y saber sobre el proceso de negocio con el que se relaciona el Producto y es por ello que la guía especifica que la forma puede variar ampliamente, ya que las técnicas para centrarnos en el usuario y las técnicas de análisis de negocio son muy variadas.
Responsabilidades
Lo que dice la guía:
“El Propietario del Producto 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.“
lo que implica:
Gestionar eficazmente el Product Backlog no solo implica agregar elementos sino también priorizarlos, refinarlos, simplificarlos e incluso eliminar aquellos que no aporten al valor.
El Objetivo del Producto guía los criterios de decisión sobre lo qué se va a entregar y es por ello que comunicarlo explícitamente es importante, ya que el equipo podrá tomar decisiones sobre cómo se va a construir lo que se necesita entregar alineados a los criterios del producto.
Crear los elementos de trabajo y comunicarlos implica encontrar maneras verbales, escritas y esquemáticas que promuevan el entendimiento compartido.
El punto anterior es la base sobre la cuál se puede asegurar que los elementos sean transparentes respecto al estado en el que se encuentran, visibles porque cualquier miembro del equipo puede ver los elementos de trabajo especificados y comprendidos porque todos los miembros del equipo pueden ser capaces de explicar cada elemento y el beneficio de contar con ese elemento.
Posibilidad de delegar
Lo que dice la guía:
“El Propietario del Producto puede hacer el trabajo anterior o puede delegar la responsabilidad a otros. En cualquier caso, el propietario del producto sigue siendo responsable. “
lo que implica:
Debido a que para que alguien pueda ser Product Owner necesita saber sobre el usuario o consumidor y sobre el negocio, se entiende que son personas con asignaciones importantes dentro de las organizaciones y en muchos casos no puede participar en todo como se quiere, por lo que en la guía permite delegar PERO esto no es sinónimo de DESENTENDERSE del equipo.
Lo que dice la guía funciona cuando quien funge como Product Owner se apoya en otros roles (ejemplo: Analistas de Negocio) sin delegar la priorización ni se desentienda del equipo. Delegar la responsabilidad a otros no funciona, si el Product Owner le delega al Scrum Master, porque los alcances de estas responsabilidades, conocimientos y habilidades son muy distintos.
Empoderamiento
Lo que dice la guía:
“Para que los Propietarios de Productos tengan éxito, toda la organización debe respetar sus decisiones. Estas decisiones son visibles en el contenido y el orden del trabajo pendiente del producto, y a través del Incremento inspeccionable en la revisión de Sprint.”
lo que implica:
El empoderamiento de alguien que funge como Product Owner se refleja en que se respeten sus decisiones y para lograrlo se necesita:
Desarrollar autoconfianza a través de nuevos conocimientos y mejorando interacciones.
Salir de la zona de confort, atreverse a tener conversaciones valientes y asertivas.
Desarrollar redes de contacto internas y externas.
Priorizar justificando por valor de usuario y valor de negocio.
Fomentar negociaciones y entendimiento compartido.
Involucrados relevantes
Lo que dice la guía:
“El Propietario del Producto es una persona, no un comité. El Propietario del Producto puede representar las necesidades de muchas partes interesadas en el trabajo pendiente del producto. Aquellos que deseen cambiar el trabajo pendiente del producto pueden hacerlo tratando de negociar con criterio con el Product Owner.”
lo que implica:
Para crear un producto hay muchas voces que pueden influir en el equipo que recibe las solicitudes de trabajo, por lo que Product Owner es un filtro de esas voces y para poder ser un filtro efectivo se necesita:
Mantener la justificación por valor, hacerla visible y transparente para todos los involucrados relevantes para que los criterios de decisión no sean por jerarquía sino por alineación hacia objetivos de negocio y de producto con beneficio directo al usuario o consumidor.
Aprender a decir “no” aunque los involucrados relevantes presionen cuando esa presión afecte la calidad del trabajo por sobrecarga del equipo o si lo que se solicita no aporta directamente al objetivo del producto.
Conclusiones
El habilitar Product Owners en los equipos ha resaltado la gran debilidad en muchas organizaciones: falta de involucramiento de las personas que saben del negocio, lo cuál se refleja en equipos que crean productos suponiendo la mayoría de los elementos de trabajo porque no hay alguien que especifique bien el rumbo.
Si un Product Owner delega el trabajo que le corresponde al Scrum Master no se lograrán los beneficios de Scrum. Porque ambas responsabilidades son complementarias pero demasiada carga laboral para que las lleve una sola persona ya que son contextos distintos, así que cuando esto sucede, quien funge como Scrum Master no ejerce bien su responsabilidad y termina ejerciendo también mal las responsabilidades adicionales.
Se habla mucho de empoderamiento pero creo que ya nos perdimos en el concepto de tanto repetirlo ya que la mayoría se divide en dos: quienes creen que el empoderamiento es de voluntad de la persona a la que se le pide ser más empoderada y los que creen que el empoderamiento tiene que ver con jerarquía cuando en realidad tiene que ver más con salir de la zona de confort y generar autoconfianza a través de nuevos conocimientos para realizar el trabajo eficientemente.
Por Vanessa Amaya
Vanessa es Ingeniera en Sistemas Computacionales por la UAG. Cuenta con 18 años de experiencia en proyectos de desarrollo de software como consultora para la implementación de prácticas de mejora en equipos, Business Analyst, Instructora, etc. Ha participado en proyectos de implementación y capacitación de marcos ágiles desde el 2012. Es Docente del cuerpo Académico del Diplomado de Ingeniería de Software Ágil en la UNAM.
Próxima fecha para nuestras certificaciones de scrum master 👇🏻
Webinar gratuito | grabación disponible
Product Owner: Razones por las que no funciona y qué se puede hacer al respecto
Los fracasos nos hacen funcionar mejor solo si los comprendemos, por eso es importante que hablemos de los escenarios y condiciones que provocan que no se alcancen los beneficios de tener un Product Owner en el equipo. En esta sesión de Agile Talk se aclararon controversias, dudas y se dieron recomendaciones para que quien funja como Product Owner lo haga de forma exitosa.
🎓 Instructor: Juan Banda (Agile Trainer). https://scrum.mx/trainers/juan-banda
👉🏻 Descarga el registro gráfico de la sesión: https://scrum.mx/informate/webinar-po...
(realizado por Vanessa Amaya durante la sesión).
