sábado, 30 de mayo de 2015

El rol del Product Owner en la práctica

Hace unos días le presenté a un grupo de gerentes los resultados de una consultoría para la que me habían contratado, con el fin de transformarse en una organización ágil. Para ello me di a la tarea de buscar una versión del video "Agile Product Ownership in a Nutshell" con subtítulos en español y la verdad es que me costó un poco encontrarlo.

Por ello he decidido compartirlo en esta entrada, pero además quiero comentar algunos de los aspectos por los que me gusta tantísimo este video y a los que creo se les debe prestar especial atención durante una transformación Ágil. Ambos, el video y mis comentarios podrán encontrarlos a continuación.



Agile Product Ownership in a Nutshell (subtitulado en español)




El Product Owner es quien da la visión

Lo primero que se menciona en el video es que el Product Owner no solamente tiene una visión del producto, sino que además se siente apasionado por ella. Es importante hacer notar que esta visión debe ir más allá del "qué se está haciendo" y que es imprescindible tener claridad sobre el "porqué" del producto que se está haciendo y comunicar claramente esta visión al equipo y a todos los interesados. En este tema recomiendo ver también el video Start with Why (subtitulado en español) de Simon Sinek. Él también tiene un libro con el mismo título pero no lo recomiendo porque es innecesariamente largo y repite muchísimo sobre los mismos ejemplos, se siente casi como un libro de autoayuda.

La automatización de pruebas es necesaria para mantener un buen paso

La automatización de pruebas es fundamental ya que esto es lo que le permite a los equipos avanzar a un paso firme, seguro y veloz. En muchas ocasiones los Product Owners pasan por alto la importancia de la automatización de las pruebas y esta omisión pasa una alta factura. Este es un aspecto algo técnico que puede escapar al ámbito de conocimiento de muchos Product Owners y por ello lo menciono acá. Si usted es un Product Owner, por favor infórmese de este tema y si su equipo no está utilizando automatización en las pruebas ayúdelos a visualizar la importancia del tema e impúlselos a incluir esta práctica dentro de su quehacer diario.

La integración continua también es fundamental

Muy de la mano de la automatización de las pruebas está la integración continua, la cual permite identificar problemas de integración tempranamente en el cliclo de desarrollo y responder adecuadamente. Ambas prácticas le ayudarán al equipo a entregar un producto de mayor calidad y con mayor velocidad a la vez que le ahorran dinero a la organización.

Sobrecargar al equipo es una estrategia perder-perder

Un buen Product Owner debe entender claramente que el sobrecargar al equipo produce desmotivación, multi-tasking y toda una serie de situaciones adversas para el avance exitoso del proyecto. Una de las tareas primordiales del Product Owner es proteger al equipo de estas situaciones y evitar que influencias externas distraigan al equipo de su meta. En este aspecto también recomiendo echarle un vistazo al libro Slack de Tom Demarco.

La herramienta más poderosa de un Product Owner



Priorizar según el valor

Una de las labores más importantes del Product Owner es mantener el backlog ordenado según el valor que las historias den al negocio. Esto es una tarea continua y a la cual se debe dedicar tiempo todas las semanas, ya que en todo momento surgen nuevas ideas, cambian los negocios o entran en rigor nuevas políticas públicas que pueden incidir en el orden de los elementos del backlog de producto.

Se debe tener muy presente además que no hay correlación entre tamaño y valor de las historias; para ello basta recordar ciertas características de algunos productos de software de gran complejidad que a la postre agregaban poco o ningún valor.

Además, para determinar el valor que una historia tiene para el negocio el Product Owner debe apoyarse en los interesados (stakeholders). Para determinar el tamaño debe apoyarse en su equipo de desarrollo.

El valor de los estimados

En Ágil el valor del ejercicio de realizar estimados está en las conversaciones, no en el valor estimado al final. Los estimados por su naturaleza están equivocados y de alguna manera se podría decir que son mentiras. Por ello actualmente hay una fuerte tendencia hacia no hacer estimaciones. Ya que este tema merece una entrada en el blog, me limitaré por el momento a invitarlos a hacer una búsqueda del hashtag #NoEstimates.

Promover un ambiente de aprendizaje

A través de una comunicación transparente y constante entre todos: el Product Owner, los Interesados y el Equipo de Desarrollo, se promueve un aprendizaje continuo. Junto con la entrega frecuente de incrementos del producto con valor, se genera un círculo virtuoso de retroalimentación y aprendizaje. El Product Owner debe asegurarse de que este proceso suceda de manera fluída y saludable en todo momento.

Agilidad de Negocio

Un buen Product Owner es capaz de identificar cuándo la relación de Esfuerzo/Valor de negocio deja de ser beneficiosa y así tomar la decisión de moverse hacia otro proyecto donde esa relación sea más favorable. A esto se le llama Agilidad de Negocio.

El punto medio

El trabajo de Product Owner es un constante ejercicio de balance y de encontrar el punto intermedio entre:

  • El corto plazo vs. el largo plazo
  • Combatir incendios vs. prevenir incendios
  • Construir el producto correcto vs. construir el producto correctamente vs. construir el producto rápidamente.

Manejo de las expectativas

En Ágil, los pronósticos se dan como un rango de tiempo. Por ejemplo al inicio de un proyecto, el pronóstico puede lucir algo así como "entre 20 y 30 semanas". Si bien la brecha es amplia, es un pronóstico honesto. Además la brecha nos da una idea de la incertidumbre y es de esperarse que a lo largo del proyecto, conforme se adquiere conocimiento esa brecha se vaya estrechando gradualmente.

Scrum a Escala

Este es otro de esos temas que requiere una publicación aparte. Por el momento me limitaré a mencionar algunos marcos de trabajo que existen alrededor de este tema:

  • Scaled Agile Framework ("SAFe") por Dean Leffingwell.
  • Disciplined Agile Development (DAD) por Scott Ambler.
  • Large Scale Scrum (LeSS) por Craig Larman ay Bas Vodde.
Si bien algunos de esos marcos de trabajo promueven una implementación a gran escala desde el principio, personalmente me inclino por dominar el tema primero en un equipo y luego escalar hacia el resto de la organización a través de un efecto "bola de nieve". A la hora de escalar Scrum será necesario la creación de un equipo de Product Owners y muy posiblemente se necesitará también la creación de un Líder de Product Owners. 

Nota: se utilizaron seis pomodoros en la elaboración de esta publicación.

No hay comentarios.:

Publicar un comentario