El verdadero origen del rol Product Owner

El verdadero origen del rol de Product Owner

Scrum es diferente a como nos lo han explicado a muchos de nosotros. Leer el blog de su co-inventor Ken Schwaber [1] es una fuente magnífica para entender Scrum bien.

El origen del Product Owner

La intención original de Ken Schwaber era hacer que los Product Managers (de negocio) se acercaran a los equipos de desarrollo para poder trabajar juntos en las oportunidades y necesidades del negocio sin intermediarios.

Ken Schwaber le puso el nombre “Product Owner” al “Product Manager” cuando asesoró al FBI. El proyecto Sentinel era un proyecto gigante para centralizar la información de inteligencia después de los atentados del 9/11/2001 y estaba paralizado cuando Ken entró a asesorarlo. El nombre “Product Owner” pretende dejar clara la autoridad en la toma de decisiones respecto a los stakeholders. Y el proyecto se reflotó en parte por ese cambio.

Pero este enfoque se ha pervertido en la mayoría de las organizaciones. La separación entre “negocio” y “tecnología” se ha mantenido en muchos casos, y por ello ha emergido el rol de Proxy Product Owner [2] que hace de intermediario entre los equipos de desarrollo y el negocio. Vamos, lo que ha hecho un jefe de proyecto toda la vida, pero con roadmaps e historias de usuario reemplazando a los cronogramas de Gantt y a la especificación de requisitos. Y en estos escenarios, los equipos de desarrollo acaban siendo “fábricas de funcionalidades” [3].

Los niveles del Product Owner- Gunther Verheyen

Niveles de Product Owner. Curso PSPO. © Scrum.org.

En este artículo veréis una comparación del rol de Product Owner y Product Manager [4] en sus diferentes enfoques.


La oportunidad del Product Owner

Según Ken, el Scrum Master enseñaría a las personas de negocio cómo conseguir agilidad de negocio a través del rol (auténtico) de Product Owner, a saber:

1) Optimizando el valor del producto para los clientes

Muchas de las decisiones que optimizan el valor dependen de entender bien los problemas de los clientes antes de buscar soluciones. Un Proxy difícilmente podrá hacerlo si recibe requisitos de stakeholders en vez de hablar directamente con los usuarios.

Además, un Proxy no puede “decir no” y por tanto, deberá implementar funcionalidades que sepa que no tienen el retorno de la inversión adecuado. Eso tampoco permite optimizar el valor.

2) Colaborando con el equipo de desarrollo

Esto significa aprovechar todo el potencial del equipo para entender los problemas y descubrir las mejores soluciones viables. Si el Product Owner “pasa historias de usuario” al equipo para que las convierta en software, realmente no está colaborando. En lugar de esto, los desarrolladores le están sirviendo.

Colaborar con el equipo de desarrollo significa también:

    • Aprovechar sus capacidades para buscar soluciones a los problemas de los usuarios. Si tratamos las historias de usuario como problemas a resolver en vez de requisitos, avanzaremos en esta dirección.
    • Considerar las sugerencias sobre la prioridad o necesidad de las funcionalidades.
    • Respetar las decisiones técnicas del equipo, incluyendo especialmente las estimaciones de esfuerzo y tiempo.
  •  
Reparto de actividades entre el Product Owner y los Developers

Actividades del Product Owner y los Developers. Curso PSPO. © Scrum.org.

Aprovechando las oportunidades que se descubren

Una vez que comienza el desarrollo del producto siempre surgen oportunidades para mejorar el valor entregado, p.e.:

    • Aprendemos cuales son los problemas reales de los usuarios.
    • Descubrimos limitaciones organizativas, técnicas o humanas.
    • Identificamos funcionalidades innecesarias o mal planteadas. Quitarlas del Backlog son oportunidades perfectas para evitar el desperdicio (waste).

La interacción directa y la transparencia con stakeholders, desarrolladores y usuarios deberían ayudar al Product Owner a descubrir esas oportunidades. El poder para tomar decisiones, deberían permitir al Product Owner aprovechar estas oportunidades.

 

Un Product Owner no es un analista

Es muy frecuente que cuando se pregunta a un Product Owner que hace, responda:

    • Escribo las historias de usuario
    • Defino los criterios de aceptación.
    • Valido las funcionalidades que entregan los desarrolladores.
    • Controlo los Sprints y las fechas de entrega.

Aunque el rol de Product Owner se puede realizar de muchas maneras, es probable que si la persona que realiza el rol emplea mucho tiempo en tareas funcionales y de calidad, deje de hacer otras actividades que aporten más valor al producto, al cliente y a la empresa.

En este artículo podéis ver que significa la validación de las necesidades del usuario y de las funcionalidades [5], de manera distribuida en varios roles y fuera del Sprint Review.

 

¿Por qué se pervierte el rol de Product Owner?

Lógicamente cada empresa es un mundo, pero existen algunos motivos comunes:

    1. Nunca se explicó bien Scrum a la empresa, y especialmente el rol del Product Owner al negocio.
    2. La organización departamental ha perpetuado al departamento de IT como gestor de proyectos.
    3. La alargada sombra del jefe de proyecto hace que muchos product owners provengan de este rol y no del negocio.

Por otro lado, es frecuente que el Product Owner se sienta como en una hamburguesa cuando:

    • la dirección y los stakeholders no le delegan, o
    • el equipo no es proactivo y autónomo porque es inmaduro, no tiene suficientes capacidades o tiene orientación a escribir código y no a entregar soluciones. Esto lastra al PO para realizar más trabajo estratégico.
Hamburguesa del Product Owner

El origen del curso Professional Scrum Product Owner

Como veréis en el artículo adjunto de Ken, este se decepcionó por la falta de entendimiento de muchas organizaciones respecto al rol de Product Owner. Por ello decidió crear el curso Professional Scrum Product Owner [6] para explicar cómo cree que se ha de realizar ese rol.

Lecturas recomendadas:

    1. Product Owners not proxies, Blog Ken Schwaber (2011)
    2. ¿Qué tipo de adopción ágil ha hecho tu empresa? Blog ITNOVE, (2021)
    3. Proxy Product Owner: ¿porque? ¿como alcanzar un autentico PO? Blog ITNOVE, (2017)
    4. Product Owner y Product Manager: ¿son iguales o diferentes? Blog ITNOVE (2020)
    5. Como validar la innovación para obtener agilidad de negocio, Blog ITNOVE (2022)
    6. Curso Professional Scrum Product Owner, Web ITNOVE 2017

¿Quieres recibir más información y recursos de calidad?

¡Sigue a Alex en las redes sociales!

Alex Ballarin

Alex Ballarin es Professional Scrum Master y Business Agility Coach. Además de este blog, publica contenido frecuentemente en las redes sociales

¡Suscríbete a nuestra newsletter mensual!

Cada mes enviamos una newsletter a más de 1.200 personas con contenidos, recursos y ofertas especiales de nuestros cursos. Queremos ofrecer contenido de calidad y sin spam.

Scroll al inicio