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.

VanesaTejada_ProductOwnerCommunicationFacilitator

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.

6 thoughts

  1. Hola Vanesa!

    Llevo un tiempo siguiéndote, hemos coincidido en varias CAS y eres un referente para mi. Simplemente me gustaría agradecerte el esfuerzo que haces compartiendo este contenido. Me siento muy alineado con tu forma de pensar acerca de los distintos roles de los equipos ágiles y es genial leer cómo las cosas que vas probando te están funcionando.

    Le gusta a 1 persona

  2. Totalmente de acuerdo … por aportar algo tendría cuidado de que:

    – El PO no se vuelva un “PO Vago” y al final los stakeholders terminen pidiendo directamente al DevTeam
    – Que los stakeholders se comuniquen “libremente” con el DevTeam (chat, mail, en persona, etc) sacandoles de su tarea con pequeñas dudas que tienen que analizar (el task switching es malísimo)

    Por otro lado:
    – ¿Qué es un stakeholder?, en scrum.org (Ken Schwaber) la definen así https://www.scrum.org/resources/scrum-glossary.
    – Se puede usar un stakeholder map para identificar a los stakeholders principales

    Un saludo y gracias por el aporte

    Me gusta

    1. Gracias a ti por tus comentarios.

      El objetivo es que el PO no sea un cuello de botella y que la relación entre los roles del producto sea fluida respetando siempre las responsabilidades de cada uno.

      Un abrazo

      Me gusta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

w

Conectando a %s