Scrum Product Ownership by Robert Galen

Durante los últimos meses, he podido leer diferentes fuentes sobre Product Management. Hace tiempo, descubrí que Scrum realmente no se utiliza para hacer proyectos, al menos la definición de proyecto que nos aporta el PMI: ”entrega de alcance, en fecha y con un coste asignado”. Scrum necesita de un Product Mindset y diferentes autores han tratado este tema. 

Tras realizar el curso de Professional Scrum Product Owner, nos recomendaron leernos el  libro de Robert Galen que aporta algunas ideas interesantes. ¡Vamos a estudiarlas! 

Toma de decisiones rápidas

Uno de los puntos que nos destaca Galen es que muchos equipos Scrum se quejan de que el Product Owner no puede tomar decisiones o, al menos, no con rapidez. El problema de fondo es que el Product Owner no tiene suficiente poder para tomar decisiones y tiene que preguntar, lo que genera retrasos. Para este tipo de situaciones, podemos tomar las siguientes alternativas: 

• Pedir perdón, en vez de pedir permiso: Tomar la decisión y esperar las consecuencias (esto requiere mucho coraje)
• Que el Scrum Master intervenga con la dirección para asegurarse que la autoridad está garantizada (esto ayuda si es un consultor externo)
• Que el Scrum Master entrene y eduque a la dirección sobre la importancia de que el Product Owner tenga autoridad. 

Funciones de un Product Owner

Para describir las funciones del Product Owner, se basa en diferentes fuentes que ha estudiado y expresa diferentes maneras de verlo. Una de ellas, es la visión de Laszio Szalvy que destaca las siete tareas top: 

• Liderar al equipo de desarrollo a través de la visión de producto y volcarlo en el Product Backlog
• Priorizar en base al valor del negocio
• Negociar el trabajo con el equipo
• Estar disponible para resolver dudas y marcar dirección al resto del equipo 
• Resistir la tentación de hacer microgestión
• No asaltar el espíritu del equipo 
• No tener miedo de tomar decisiones difíciles 

Estas no son las tareas oficiales de la Scrum Guide, pero, según mi criterio, aportan una visión más profunda de lo que debe ser un Product Owner. 

Fomentando la Transparencia

Cómo líder, hay muchas funciones que debe hacer un Product Owner. Una de ellas es la de generar transparencia para, a su vez, generar confianza con el equipo. En los modelos tradicionales, nos basamos solo en la planificación para transmitir transparencia. Según Galen, siempre vamos mal en la planificación. Para cambiarlo, propone varias acciones que puede tomar un Product Owner de cara a generar transparencia para los interesados: 

• Invitar lesa que vean la zona del equipo y sus radiadores de información: Sprint Backlog, gráficos de Burndown, planes…
• Invitarles a asistir a alguna Daily Scrum para escuchar los progresos del equipo 
• Invitarles a asistir a alguna Sprint Planning para que vean el esfuerzo que pone el equipo
• Asegurarse de que se les incluye en la mayoría de Sprint Reviews, en muchos sitios no se les da importancia, pero es el momento clave de análisis del Sprint y del producto. 

Recordar que el Scrum Master es una ayuda en cuanto a Transparencia se refiere. Es importante que colabore con el Product Owner en ser transparente y que, cualquier persona de la organización, pueda consultar cualquier aspecto del producto. 

El consejo final es: sé un libro abierto y, sobretodo, sé honesto. 

La calidad y el Product Owner 

El autor deja muy claro que la calidad es una función de todas las personas del equipo, es algo que debemos tener en nuestro ADN, y no una actividad que hacemos al final. Si tienes que hacer test de calidad al final del desarrollo, es que es demasiado tarde. 

Algunas prácticas core que podemos implantar como un equipo Scrum: 

• Haz transparente el Product Backlog y haz preguntas sobre él a los interesados continuamente 
• Escucha bien las necesidades de los interesados y trata de asegurar bien los criterios de aceptación 
• Utiliza pair programming y code reviews como técnicas de calidad 
• Haz re-factor, sobretodo si recibes un código heredado de baja calidad 
• Usa automatización de test 
• Nunca te quejes a la dirección sobre la falta de calidad. En vez de eso, sé profesional con tus principios y estándares de calidad. 

La influencia del Product Owner

En una parte del libro, Robert Galen nos contaba una historia de cómo un Product Owner al que acompañó influía negativamente en el equipo. En una ocasión este equipo había hecho un Sprint con muchísimas incidencias. Durante la retrospectiva, estuvieron hablando de la situación. El equipo consideraba que habían hecho una estimación demasiado optimista (solo tuvieron en cuenta el happy path) debido a la presión del Product Owner. Tras indagar en este asunto, el equipo admitió que realmente el Product Owner nunca dijo nada. 

El origen del problema, es que, el Product Owner no paraba de mostrar su preocupación con la presión que recibía del CEO y de los clientes, y que había que llegar con todo. El equipo, al tener una relación cercana con el Product Owner, asumió el riesgo. El resultado fue que generaron incidencias y quejas en los clientes. Por tratar de hacer más, acabaron haciendo menos. 

Cambiaron de estrategia y decidieron primar más la calidad y empatizar más con el equipo. Era mejor hacer algo menos pero con un nivel de calidad aceptable para los clientes. 

Product Backlog en equipo

Otro de los puntos que me llamó la atención de la propuesta de Robert Galen es el concepto de Product Backlog en equipo. Cuando comenzamos un nuevo Producto y tenemos que crear el Product Backlog, ¿por dónde empezamos? Es un ejercicio difícil.

Robert Galen narraba una historia en la que estuvo acompañando a un Product Owner que estuvo dos semanas, casi sin dormir, creando el Product Backlog “perfecto”. El equipo mientras estaba esperando a que el Product Owner lo presentara. El Product Owner estaba estresado. 

Se sentó con el Product Owner y le propuso hacer un Taller de Historias de Usuario al estilo Mike Cohn, pero con el equipo. De esta manera, podemos empezar a “enganchar” al equipo con el Product Owner. Enseñó al Product Owner que, por encima de escribir las historias, él debía ser un facilitador del Product Backlog y que dejara de ir por libre a la hora de crear el Backlog. 

Tras el taller el Product Owner lo felicitó, se dio cuenta de la cantidad de ideas que podía aportar el equipo para el producto que iban a desarrollar juntos. 

Criterios de Aceptación

Otra de las curiosidades que podemos encontrar en este libro es la preparación de los criterios de aceptación. En este caso, Robert Galen nos traslada varios criterios que podemos tener en cuenta: 

• Una buena historia debe tener mínimo cinco criterios de aceptación
• Si utilizamos puntos de historia, no debe pasar de 13. En caso de que lo haga, deberemos de dividir. 
• El equipo ha examinado la historia varias veces en diferentes sesiones de refinamiento 
• Si es necesario, se puede hacer un ejercicio de spike para estudiar el impacto con la arquitectura y las implicaciones. 
• El equipo ha entendido cómo abordar la historia a nivel funcional y no funcional
• Cualquier dependencia con otras historias está conectada y es sincronizable 
• La historia se alinea con el Objetivo del Sprint y se puede demostrar
• Hasta que un PBI no cumpla todas las condiciones anteriores no podemos introducirlo en el Sprint  

Priority Poker

La priorización es clave en el trabajo del Product Owner. Al igual que el Planning Poker, el Priority Poker funciona con cartas del 1 al 9, siendo el 9 máxima prioridad. Cuando trabajamos un Item del Backlog, podemos tener un debate con las personas que deben priorizar, y usar este ejercicio para tomar una decisión. 

Además, podemos enriquecer la técnica asignando un número o un % máximo de elementos de máxima prioridad. De esta manera, evitamos que todo sea un 9. 

Centrándonos en el Objetivo del Sprint 

La importancia del Objetivo Sprint es alta ya que se relaciona con la capacidad de poner foco en lo que hacemos. El Objetivo del Sprintes clave para un Product Owner, y por eso le dedica una gran parte del libro. Una propuesta de Robert Galen es utilizar la técnica del elevator pitch para definir el Objetivo del Sprint. De esta manera, podemos dar una explicación rápida de lo que nos aportará este Sprint a nuestro producto si alguien nos pregunta. 

Un antipatrón del Objetivo del Sprint es hacer un listado de funcionalidades. Tenemos que pensar en un aporte de valor directo, no en un listado de cosas que queramos. 

Un debate interesante que plantea Galen es sobre si el Sprint Goal es Huevo o Gallina, como ya lo trabajamos en el blog en otro artículo anterior. 

Definiendo el MVP

El Producto Mínimo Viable (MVP en inglés) es un concepto muy de moda en las organizaciones. Es saber el mínimo con el que podremos salir al mercado. El autor nos propone un ejercicio interesante llamado “black-white”. Consiste en pintar 3 columnas, siendo la de la izquierda “black” y la de derecha “white”. En la columna “black,” situamos todos los elementos que debe tener nuestro producto mínimo, mientras que en la blanca lo que se queda fuera. La columna intermedia es la zona “gris”, que nos permite poner aquellos elementos de los que debemos debatir. 

Este ejercicio es muy bueno para que el Product Owner pueda centrarse en las expectativas y pueda ir trabajando con los interesados lo que vamos a poder lanzar al mercado. 

Iteration 0

El Sprint 0 es siempre polémico dentro del mundo del desarrollo ágil. Está claro que no pertenece a Scrum, pero para muchas organizaciones es muy útil porque ayuda a tener una definición antes de valorar si hacemos un determinado producto o cómo.

La visión que nos aporta Galen es interesante. Según él, no deberíamos tener Sprint 0, siempre y cuando tengamos resuelto las siguientes cuestiones: 

• ¿Tenemos un equipo que ya ha trabajado junto y con experiencia?
• ¿Saben Scrum?
• ¿Tienen las herramientas adecuadas y están sentados juntos?
• ¿Son capaces de arrancar sin tener un Product Backlog?
• ¿El Scrum Master tiene experiencia?

Estas preguntas y otras más son las que deberíamos tener resultas. Si las tenemos, ¿para qué vamos a esperar un Sprint para entregar valor a nuestros clientes? 

Audiencia en la Sprint Review

Es importante que el Product Owner tenga muy claro que es responsable de la audiencia que acude a la Sprint Review. Este evento es el evento de negocio por excelencia, porque analizamos nuestro producto y su impacto en el mercado. Necesitamos feedback y es importante disponer de las personas que puedan proporcionarlo.

El autor nos propone que, dado que las personas que deben acudir suelen estar ocupadas, tratemos de calendarizar las reuniones con varios Sprints de adelanto, así podemos conseguir que la audiencia correcta asista. 

Por otro lado, la preparación de la Sprint Review es importante. Un consejo vital es que enseñemos más software funcionando que PPTs. Es importante entender que el objetivo es entregar valor, y el software que no funciona no es valor para nadie. 

Conclusiones

El libro de Robert Gallen debe ser de obligada lectura para cualquier Product Owner, que se precie, y para aquel Scrum Master que quiera aprender maneras de acompañar a su Product Owner. El libro trata muchos más temas como el escalado, pero no íbamos a contarlo todo. Si os decidís a leerlo, esperamos con ansia vuestros comentarios.