Siempre he considerado que el Product Owner debe ser un excelente relaciones públicas del producto, principalmente creo que debe ser una persona que facilita las relaciones entre los roles alrededor del producto, evitando así ser un cuello de botella o un impedimento para que la información fluya.

He vivido la época en la que casi se prohibía que un Stakeholder hablara con un desarrollador, porque le pedía que le hiciera cosas que no estaban en la prioridad, y lo peor es que ¡se las hacían!. Recuerdo que prohibir la relación no sirvió de nada, sobre todo porque había muchos casos en los que la estrecha colaboración de estos roles para realizar una entrega era muy valiosa.

Si vivimos estas situaciones en nuestro día a día, tenemos por delante una gran oportunidad de transformar una posible ‘lucha’ en acuerdos de trabajo que favorezcan la colaboración, coordinación y entrega de valor en equipo. El Product Owner puede hacer una gran labor para optimizar la relación entre los desarrolladores y los Stakeholders, algo que permita sacar el mayor valor posible a la colaboración entre ambos pero que evite, todo lo posible, poner en peligro la entrega del producto en curso. Os voy a compartir algunos de los acuerdos que definimos en un equipo:

• Cuando un desarrollador tenía dudas de una funcionalidad que estaba desarrollando, en caso de que el Product Owner no estuviera disponible, podía ver en la herramienta de gestión del Product Backlog quien era el Stakeholder principal y así, contactar con él directamente.
• Cuando un desarrollador realizaba un desarrollo que era algo complejo y novedosos para el producto, a veces quería hacer una pequeña demostración al Product Owner antes de la revisión del Sprint, si el Product Owner no estaba disponible podía verlo con el Stakeholder principal.
• Cuando un Stakeholder se acercaba al equipo y pedía una ampliación del alcance de alguno de los elementos del Product Backlog en curso, el desarrollador tomaba nota y respondía que debía consultarlo antes con el equipo y el Product Owner.
• Cuando un Stakeholder se acercaba al equipo y pedía algo nuevo para incluir en el Product Backlog, éste le respondía que hablara con el Product Owner.

Lo más bonito de estos acuerdos, es que son el resultado de retrospectivas donde han participado los Stakeholders. El éxito de que se hubieran definido y respetado por ambas partes, ha sido gracias a haberlo hecho en conjunto, tratando ejemplos reales, el impacto que han tenido en el flujo de trabajo, en el producto y en el lado personal. Decir que estos acuerdos han ido evolucionando a medida que ambos roles han madurado y optimizando el flujo de trabajo.

Puede que os preguntéis al leer estos ejemplos: ¿pero por qué el Product Owner no está disponible? Sencillamente, porque es un ser humano que a veces se pone enfermo, o decide irse de vacaciones, porque está reunido en ese preciso momento, o porque por algún motivo inesperado ha tenido que ausentarse del trabajo. Sea el caso que sea, el negocio debe seguir funcionando y el producto debe seguir funcionando, porque los clientes siguen ahí y no van a esperar por nadie – The show must go on!.

El Product Owner nunca debe ser un impedimento en la comunicación entre los Stakeholders y los desarrolladores del producto. Nunca. El Product Owner debe ser un facilitador de esta comunicación con el objetivo de hacer un mejor producto, tanto en la fase de descubrimiento como en la fase de entrega, debe asegurarse de que hay unas ‘reglas del juego’ que todos comprenden y respetan, con el objetivo de que el trabajo fluya de la mejor manera posible.