• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

Product Owner

Product Owner, improvisación o adaptación

La agilidad no ha parado de extenderse en los última década e incluso las organizaciones que miraban con recelo todo este movimiento están dando sus primeros pasos y viendo cómo pueden sumarse, aumentando así su competitividad. ¿Cómo está conviviendo en estas compañías mentalidades tan diferentes? ¿Cómo están respondiendo los Product Owners a las necesidades?(Extra: ¿qué es la transformación digital?)

Emma es una project manager en una gran compañía. Una telco internacional que solo en España cuenta con más de 10.000 trabajadores entre internos y externos. Ella trabaja en la parte que en su empresa llaman legacy. En otras muchas esta parte de la compañía la llaman waterfall o tradicional. Trabajan como siempre lo han hecho y ahora tienen que convivir con una parte “agile” (el uso de las comillas no es una casualidad) que ha surgido en la compañía y ha empezado a trabajar de otra manera.

Para gestionar la parte que le toca en toda esta gran maquinaria, Emma necesita cuadrar dependencias, esfuerzos y fechas. Cuando interactúa con equipos que están en la party legacy de la empresa, se entienden. Todos hablan el mismo idioma. Pero cuando se dirige a las nuevas estructuras ágiles y sus Product Owners recibe un: “No tenemos fecha concreta. Nosotros trabajamos en agile, así que no tenemos fechas”. Emma está frustrada y, con razón, duda sobre la operatividad – e incluso la profesionalidad – de los equipos ágiles.

La planificación (continua) es clave 

Existe un falso mito alrededor de la agilidad y la planificación. Analicemos por encima Scrum, por ejemplo:

  • El Product Backlog contiene el futuro del producto. Debe estar ordenado, refinado, estimado y con él es sencillo conocer cuáles serán los siguientes pasos.
  • En la Sprint Planning se crea un plan para alcanzar nuestro Sprint Goal durante el Sprint. 
  • La Daily Scrum es un evento para crear un plan de las siguientes 24h, una vez inspeccionado como va el plan del Sprint. 
  • La Sprint Review es un evento de negocio que pertenece al Product Owner dónde se analiza la situación actual del producto, del mercado, obtendremos feedback de los Stakeholders y re-planificamos el futuro de nuestro producto y lo plasmamos en el Product Backlog.
  • La Sprint Retrospective es una oportunidad para el Scrum Team de planificar acciones de mejora en el Definition of Done, procesos, herramientas o personas. 

Como podemos comprobar existe una planificación continua. La clave del éxito de la agilidad en entornos complejos no reside en la falta de planificación. Reside en darle más importancia a la planificación en sí misma, a las conversaciones, a la transparencia que subyace tras cada planificación, que al plan en sí mismo y estar dispuesto a actualizar el plan con cada nuevo descubrimiento que nos pueda aportar una ventaja competitiva. (Extra: Cómo Scrum nos ayuda a alcanzar la agilidad de negocio)

Planificando tendré oportunidad de adaptación

Tener una planificación es básico para poder desarrollar un producto o un servicio de forma profesional. El tipo de respuestas que se ven en desarrollos “ágiles” como el que le daban a Emma “Es que trabajamos en agile y no sabemos cuándo vamos a tener nada” demuestra que no es un desarrollo agile en absoluto y falta product ownership. Es un desarrollo donde se está improvisando. Improvisar y adaptar no es lo mismo. Inspeccionar y adaptar es la clave de la agilidad y eso solo puede ocurrir cuando tengo un plan, y soy capaz de modificar mi plan según las necesidades del mercado. 

Una respuesta a Emma en un entorno ágil podría ser: “Emma, con lo que sabemos hoy y con los datos históricos que tenemos, creemos que estará este día X. Cada dos viernes es nuestra Sprint Review y damos transparencia sobre la situación que tenemos y siguientes pasos. Pásate si estás interesada. Además, en este lugar está nuestro Product Backlog y release plan actualizado”. Bastante diferente, ¿no crees?

La falta de Product Ownership

Según mi experiencia el gran mal que azota a las empresas es la falta de liderazgo del producto. Muchas llamadas comienzan con “es que no sale el trabajo”, “es que los equipos no están comprometidos”, “es que no se hacen las cosas bien”. 

Cuando escarbas descubres que no existe nada relacionado con la gestión del producto (métricas de valor, releases maps, estrategia y visión de producto alineada con estrategia y visión de compañía) o gestión de la demanda. Esto hace que todo el mundo corra, pero en círculos. Todos están exhaustos, muchas horas trabajadas, mucha presión y nada de valor generado. ¿Os suena esta sensación que todos hemos tenido?

En muchos casos puedes ver un Agile Coach que corre a trabajar para que el equipo esté unido, tengan dinámicas divertidas y buena comunicación. En mi experiencia puedo decir que me he cruzado con equipos con más necesidad de tener una gestión de producto bien aterrizada, profesionalizada y bien ejecutada que con necesidad de mejorar sus interacciones sociales. Eso es algo que se alcanza cuando el equipo (incluyendo al Product Owner) se relacionan alrededor de un objetivo claro y ponen todo su conocimiento y esfuerzo al servicio del beneficio de sus clientes y, por tanto, del revenue para la empresa.

El empoderamiento del Product Owner

Un Product Owner de una gran aseguradora se quejaba de que no tenía ningún tipo de poder de decisión sobre el producto, que le gustaría poder tomar más decisiones y tener más responsabilidad. Yo le pregunté que dónde podría ver sus diferentes horizontes de planificación, sus futuras entregas a los clientes y como esperaba que esas entregas impactaran en las métricas de negocio. “No tengo nada de eso” fue la respuesta.

Para crear productos de alto valor el Product Owner debe estar empoderado. Y aquí hay un contrato de dos partes. La empresa, claro está, debe darles capacidad de maniobra y libertad. Pero no hay que olvidar que el Product Owner debe ganarse la confianza. Tener al menos una visión de producto, un roadmap, un release map y qué métricas vamos a tomar para ver si el valor del producto es el esperado, eso es básico. Sentarse a pedir más responsabilidad con todo este plan bajo el brazo suele ser más sencillo.

Conclusion

El Product Ownership brilla por su ausencia en el desarrollo ágil de productos. Esto nos lleva a falta de planificación e improvisación que suele terminar en desastre. Este “Product Management Vacuum” ocasionado, en muchas ocasiones, por tener Product Managers (o Product Owners) más enfocados en gestión de personas, en planes de proyecto y en cumplir hitos que en tener una visión, generar valor y validar que, con los usuarios reales, que esto está ocurriendo.

El foco de un Product Owner debe estar en las tres V: Visión, Valor y Validación. Una vez que tengamos esto, podemos empezar a trabajar en un desarrollo ágil de producto que permita alcanzar agilidad empresarial a toda la organización.

Si quieres saber más sobre Product Ownership:

  • Los 10 mejores libros para Product Owners
  • Nuestra academia online: Vídeos grabados y exámenes. Organizáte como quieras.
  • Nuestros cursos virtuales: Para facilitar la formación en tiempo de COVID estamos dando nuestros cursos en formato remoto.
  • Path de Scrum.org para Product Owners: Conjunto de recursos muy recomendable para todos los perfiles: Scrum Masters, Agile Coaches, Product Owners o jefes de proyecto

Facilitación Gráfica – Product Owner

¿Qué es un Product Owner? ¿Cuáles son sus funciones en el equipo? Estas preguntas son las que vamos a intentar responderte esta semana en el espacio de facilitación gráfica.

El Product Owner

Es la persona responsable  de maximizar el valor del producto que crea el Development Team. Para ello se responsabiliza de uno de los artefactos que utilizamos en Scrum, el Product Backlog, donde se encuentran los requerimientos del producto. Sus decisiones deben ser respetadas por e equipo y la organizacón.

Funciones

Entre sus funciones se encuentran:

  • Ordenar y expresar de manera clara los items del Product Backlog
  • Hacer visible y entendible el Product Backlog
  • Optimizaar el valor del producto
  • Gestionar el presupuesto
  • Controlar el riesgo de mercado
  • Contacto con stakeholdersProduct Owner

Los 7 pecados capitales del Product Owner

1. Pensar que su responsabilidad es gestionar el Product Backlog

La responsabilidad del Product Owner es maximizar el valor del Producto del que es responsable. Eso incluye, entre otras tareas, gestionar el Product Backlog, pero no está limitado a ella. El Product Owner realiza muchas otras tareas que están enfocadas a desarrollar el producto que el cliente quiere. Esa es su labor principal.

2. No estar disponible para el equipo

La colaboración entre el equipo de desarrollo y el Product Owner no solo es necesaria sino que es fundamental. Si el Product Owner es responsable de construir el Producto correcto, el equipo de desarrollo lo es de hacerlo correctamente. Esto requiere de una comunicación fluida y continua, no sólo en los distintos eventos de Scrum, sino también manteniendo Transparencia, Inspección y Adaptación, que son los pilares del empirismo, en el que está basado Scrum.

3. No gestionar presupuestos

Cómo parte de las responsabilidades del Product Owner, se incluyen todas las responsabilidades clásicas de negocio, y esto incluye gestionar los presupuestos. Es labor del Product Owner decidir si habrá un próximo sprint, que features serán incluidas en la próxima release, así como el esfuerzo económico destinado al desarrollo. Por ejemplo, si el equipo quiere incorporar a otro ingeniero, es responsabilidad del Product Owner decidir que porcentaje del presupuesto le asignará al mismo.

4. No conocer a los stakeholders

Muchos Product Owners no han visto a un cliente en toda su vida profesional. Se limitan a hacer lo que les dicen los jefes. Bien, si esto es así, entonces probablemente la compañía esté haciendo Scrum aficionado. El Product Owner es responsable de la comunicación con los Stakeholders, de entender cuales son sus necesidades, y de tomar decisiones en consecuencia.

5. Creer que es el jefe

Algunos Product Owners ven su responsabilidad sobre el producto como la vía para ser el jefe. Muchos incluso son jefes funcionales, siendo esto una malísima decisión. El Product Owner tiene completa responsabilidad y es dueño del producto. Punto. Tiene que saber encontrar puntos de colaboración con el Equipo de Desarrollo y el Scrum Master para conseguir hacer un producto excelente.

6. No reportar

Contrariamente a lo que la gente cree, en Scrum la labor de reportar no es del Scrum Master, ni del Equipo de Desarrollo. Es labor del Product Owner reportar adecuadamente a los Stakeholders, asegurarse de que estos tienen un conocimiento de lo que se está haciendo. Hay distintas maneras de hacerlo, y todas requerirán grandes dosis de liderazgo por su parte.

7. No acudir a los eventos de Scrum

Curiosamente, hay Product Owners que nunca van a un Sprint Review, o a una Retrospectiva. Piensan que eso es cosa del Equipo de Desarrollo y del Scrum Master. Nada más lejos de la realidad. El PO es el primer interesado en estar en los eventos para asegurarse de que el Producto que se está desarrollando lo hace conforme a lo que ellos esperan. No hacerlo así es irresponsable.

El rol de un Jefe de Proyecto en Agile

Cada vez se ven más ofertas -seguirá creciendo en España- que requieren Agile Project Managers o Agile Managers. Eso da lugar a dudas sobre lo que realmente hace un jefe de proyecto ágil. Veámoslo.

Dentro de las diferentes metodologías ágiles, Scrum es la que más específicamente habla de Project Management. En contraposición con metodologías clásicas de desarrollo de Software, el rol del Project Manager está distribuido entre los diferentes roles del equipo Scrum: El Scrum Master, El Product Owner y el equipo de desarrollo.

El Product Owner es responsable de los aspectos de negocio del desarrollo, incluyendo el orden en que el producto se desarrolla y que éste sea desarrollado correctamente. También se encargar de las proyecciones, presupuesto y gestión de los diferentes interesados en el desarrollo del producto (stakeholders).

Ninguna metodología ágil describe el rol de Jefe de Proyecto. Ni siquiera el PMI-ACP, la certificación oficial del Project Management Institute le da una posición destacadaEl Scrum Master se encarga de gestionar el proceso Scrum, funciona como un Coach del equipo, y su autoridad se extiende únicamente al proceso. El Scrum Master no es responsable por el éxito o el fracaso de los proyectos en Scrum. El Scrum Master ayuda al Product Owner a seguir el progreso del proyecto y a reportar a los stakeholders.

El Equipo de Desarrollo se encarga de construir el producto, así como realizar los planes más a corto plazo durante el Sprint Planning, que luego actualizan durante el Daily Scrum, como conseguir los objetivos de proyecto a través de los Sprint Goals, las prácticas necesarias para asegurar la calidad y la mejor manera de construir técnicamente el producto.

Como se puede ver, las responsabilidades clásicas de un Jefe de Proyecto en Scrum están muy bien distribuidas entre los distintos roles en Scrum.

¿Significa esto que no hay necesidad de Jefes de Proyecto en Scrum?

Efectivamente. Los Jefes de Proyectos clásicos, se hagan llamar Agile o no, tienden a ser una interferencia -y habitualmente un impedimento- en proyectos ágiles porque no tienen ninguna responsabilidad de la que hacerse cargo y, en caso de estar, tarde o temprano terminaran colisionando con alguno de los roles existentes en Scrum.

Las empresas que tengan Jefes de Proyecto y quieran adoptar agilidad, especialmente en el caso de Scrum, deben de pensar cual es el nuevo papel que quieren darle a estas personas antes de embarcarse en una transición ágil, dado que, tarde o temprano, en más que probable que se produzcan luchas de poder que no tienen ningún beneficio ni aportan nada a la creación de productos.

 

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad