El Product Owner SÍ va a las retrospectivas. ¿Quién dijo lo contrario?

El Product Owner es parte del Scrum Team y SI va a las retrospectivas. Pensar lo contrario evidencia un pobre conocimiento de Scrum.

Esta semana tuve un curso Professional Scrum Product Owner y discutíamos con un asistente el objetivo y dinámica de la retrospectiva del sprint. Me contó una cosa sorprendente: un conocido formador de una conocida organización de Scrum le explicó que el Product Owner no debía ir a las retrospectivas para que los desarrolladores pudieran hablar con libertad. Si esto lo hubiera dicho un formador low-cost que aparenta liderar una organización fictícia internacional, no me habría llamado la atención tanto, pero no era el caso y me pareció preocupante.

Solo leyendo la Scrum Guide, ya tenemos la respuesta: “The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint”. Hablamos del Scrum Team completo, no del Development Team. Pero aprovechemos para reflexionar sobre esta duda más allá de seguir la regla de manera automática.

 

Scrum es más que elementos y reglas: se sustenta en valores

Es probable que estos mitos vengan por la visión simplista de Scrum que abunda en muchos lugares, donde se prioriza la visión mecánica de Scrum como un conjunto de eventos y reglas, y se ignora la cultura, principios y valores que deben sustentar cualquier organización que sea ágil de verdad. Utilizo frecuentemente la metáfora del iceberg para explicar que, aunque los procesos, marcos de trabajo y prácticas ágiles son necesarios para habilitar una organización ágil, son únicamente una base y que la parte difícil de una transformación ágil consiste en el cambio cultura.

La incorporación explícita de los 5 valores de Scrum a la Scrum Guide de 2016, quería destacar la importancia de estos valores a nivel grupal y organizativo.

Si consideramos como los valores de Scrum deberían hacernos pensar la Retrospectiva, vemos como no tiene ningún sentido pensar que el Product Owner no debería formar parte de este evento:

1. Coraje: si los miembros del equipo de desarrollo no se atreven a decir lo que piensan delante del Product Owner, puede representar una falta de coraje. No se pide a nadie que sea un héroe: si alguien teme razonablemente que sus palabras se vuelvan contra si es normal que no las exprese, pero en otras ocasiones el permanecer callado podría deberse a la pasividad o al deseo de permanecer en su zona de confort.
2. Foco: ¿como nos enfocamos en las metas del equipo Sprint, como es la mejora continua, si no trabajamos duro por el entendimiento y por apoyarnos entre los miembros del equipo?
3. Compromiso: si tanto el Product Owner como el Equipo de Desarrollo no se esfuerzan por una Retrospectiva auténtica y productiva, ¿qué compromiso real tienen con el éxito del equipo?
4. Respeto: Scrum supone un respeto por el profesionalismo, por las responsabilidades del resto de roles y por los clientes que reciben los productos. No esforzarse por salvar las diferencias y mejorar continuamente, supone una falta de respeto a estos elementos.
5. Franqueza: no decir lo que se piensa realmente, aunque pueda ser incómodo a veces, supone una oportunidad perdida para entenderse entre los diferentes roles, y probablemente algunos desarrolladores estereotipen el interés del Product Owner, o bien no entiendan profundamente su contexto.

 

El Product Owner puede ayudar muchísmo en la mejora

Además de entender los valores, el rol de Product Owner es vital para el éxito de los proyectos y para contribuir al cambio organizativo. Que asista a la retrospectiva, más allá de generar confianza, empatía y sensación de pertenencia con el equipo de desarrollo, presenta múltiples beneficios evidentes:

1. Gestiona el presupuesto: puede ayudar (o dificultar) a que se realice la mejora continua del equipo (kaizen)
2. Gestiona las expectativas y comunicación con los externos: puede presionar para realizar cambios organizativos con cierta efectividad, pues tiene interlocutores de negocio y puede expresar el impacto de no hacer dichos cambios.
3. Debe escudar al equipo de las interferencias de los externos: puede entender en la retrospectiva como su rol puede contribuir a mejorar la efectividad del equipo.
4. Debe tener una dedicación suficiente para realizar las responsabilidades del rol: puede entender en la retrospectiva como su eventual falta de dedicación impacta a las decisiones que debe tomar el equipo.

 

Conclusiones

En definitiva, la Retrospectiva es un evento esencial para traer mejora y agilidad a la organización, un beneficio más trascendente aún que el éxito de un proyecto individual.