La relación del Product Owner con los Stakeholders

Como Product Owner enseguida te has dado cuenta de la gran importancia que tiene tu relación y la del Equipo Scrum con los Stakeholders. 

Cada Stakeholder tiene su propia necesidad que atender. Lo suyo es siempre “lo más importante para la supervivencia de la compañía”, y no van a desaparecer. Tendrás más o menos Stakeholders dependiendo de las diferentes tipologías de producto y de la complejidad de las cadenas de valor existentes. Además, probablemente sean ellos los que tienen acceso directo al cliente final, al que compra vuestro producto, y como Product Owner esa conexión es vital para ti.
Así que, salvo que tengas la suerte de ser el auténtico dueño del producto, vas a tener que entenderte con ellos.

Entenderte con los Stakeholders para obtener información útil es la parte que mayor frustración te puede generar, y sin embargo la más divertida e interesante de ser Product Owner. Te permitirá construir un buen Product Backlog y priorizarlo basándote en las necesidades de la compañía y sus clientes. Te dejo algunos consejos para sobrellevarlo mejor y sacarles más partido.

Crea una red de colaboradores

Fomenta, junto con los otros Product Owner y los Scrum Master, espacios formales en los que relacionarte con los diferentes niveles de responsabilidad de las áreas de negocio. Estos son algunos de los que hemos puesto en práctica en varios de nuestros clientes:

W

Una sesión mensual de negociación entre las áreas de negocio, para priorizar el Backlog del área de IT. 

Te permitirá llevar el debate sobre qué debe realizarse primero a donde corresponde, a las áreas de negocio. Ya que son ellas las que tienen la visión global de la compañía.

Te evitará mantener múltiples reuniones para tratar de cuadrar las diferentes solicitudes de cada área. En una sola sesión, se acuerda todo.

W

Una sesión bimestral o trimestral de Planificación del área de IT, en la que los diferentes Equipos Scrum realicéis una planificación de alto nivel junto con las áreas de negocio.

Te permitirá visualizar cómo se distribuye lo priorizado en la sesión de negociación a lo largo de los Sprints.

Te permitirá visualizar dependencias internas y con terceros.

Tendrás una planificación consensuada con tus Stakeholders.

W

Incorporar cuanto antes a las personas que representan a las áreas de negocio con las que trabajas en el día a día a la Sprint Review.

Ayudará a subir el nivel de la sesión.

Os “obligará” en cierto modo, a mostrar incrementos reales de producto. Usa las PPTs para ayudarte en las explicaciones, nunca para sustituir una entrega a medias.

W

Una sesión bimestral o trimestral de Review, a la que asistan los responsables de las áreas de negocio, directores, etc… Es decir, las capas del management que no están en el día a día, pero marcan la dirección en la que va el negocio con sus decisiones.

Gestiona inteligentemente las expectativas

Controla las expectativas, sobre todo al inicio. Estáis arrancando, aprendiendo cómo se crea y gestiona un producto desde una perspectiva Agile, aprendiendo sobre vuestra propia capacidad. Mantén los pies en el suelo y evita pecar de optimismo. Comprometerse a algo poco realista se convierte en punto innecesario de presión o agobio más.

Se conservador en los primeros Sprints, siempre será mejor decir que vas a hacer menos y luego abrir la posibilidad a que hagáis más, que al revés. Generas más frustración creando falsas expectativas, que siendo tacaño en la planificación.

Eso sí, estate atento a que esto no se convierta en lo habitual, y ponlo sobre la mesa para debatir en las Retrospectivas.

Aprende a utilizar el sí y el no ahora de manera efectiva

Atrévete a decir claramente “Ahora no, por que supone…” y “Sí, aunque eso implica…”. Ni todo lo que llega tenemos que atenderlo inmediatamente ni todo debe quedarse para más adelante. Lo que te aconsejo es hacer siempre visibles las consecuencias de cambiar vuestra planificación.

Todo lo que llega fuera del plan tiene impacto, menor o mayor, pero lo tiene. Cuéntale al Stakeholder que te esté pidiendo algo adicional (o urgente o megasúperurgente de vida o muerte), las consecuencias de abordarlo inmediatamente. Hazle responsable de la decisión de atrasar las peticiones de otras áreas o de sus propios compañeros de área. E inmediatamente después comúnicalo a todas las áreas de negocio afectadas. Puede ser un correo o una sesión rápida de 15 minutos, involucrando a quién ha provocado el cambio en el plan.

Si tienes la suerte de haber formalizado la sesión de negociación, siempre le podrás remitir a que lo lleve a la siguiente y negocie con el resto de sus iguales. Y si no puede esperar, visualiza el impacto.

Recuerda que no estás solo

Apóyate en el resto de compañeros de tu Equipo Scrum. El Scrum Master te puede ayudar a facilitar y dinamizar las sesiones con los Stakeholders, a prepararlas para que sean más efectivas. Incluso es un buen apoyo para hacer pedagogía.

Los Desarrolladores seguramente a lo largo de los años tendrán una relación estrecha con algunos Stakeholders. Aprovéchala para llegar a las personas con las que hayas tenido menos relación, o para conseguir un mejor consenso sobre los cambios de planificación. Incluso te puedes apoyar en los que tengan buenas dotes de comunicación.

No estás solo en la relación con los Stakeholders, eres responsable de esa relación pero, como hemos dicho en otras ocasiones, sigues sin tener que hacerlo todo solo.

Introduce tus primeros cambios

Ojalá estos consejos te sirvan para mejorar tu relación con tus Stakeholders. Introducir nuevas ideas en tu día a día puede resultar abrumador. Haz un ejercicio conmigo. Escribe una lista de las 5 ideas más potentes que te gustaría poner en marcha. Para cada una de ellas, apunta:

  • Qué pasa si no lo intentas.
  • Qué pasa si lo intentas y lo consigues.
  • Qué pasa si lo intentas pero no lo consigues.

Quiénes son tus aliados claves para introducir ese cambio y cómo los vas a implicar. Con esta información, prioriza y elige qué vas a hacer primero. ¡Ánimo!

También te puede interesar.

Por dónde empezar como Product Owner que viene de Tecnología

Estás dando tus primeros pasos como Product Owner, tras haber pasado años diseñando y desarrollando software. Te enfrentas a varios dilemas.

Cómo mejorar tu Scrum Daily

En ocasiones nos encontramos con equipos en los que la Scrum Daily se ha convertido en un evento individualista donde cada miembro del equipo de desarrollo comenta las tareas realizadas durante el día anterior, muchas veces con cierto carácter de reporte. Sin embargo, la daily es un evento colectivo donde a través de la inspección y adaptación se traza un plan de trabajo del día para el equipo.

Las consecuencias de un Backlog interminable

Nuestro Product Backlog con el tiempo se va llenando y convirtiendo en un Backlog interminable. En este artículo te planteo las consecuencias más relevantes que tiene.

Lo que te estás perdiendo por hacer «tu» Scrum

¿Qué ocurre si decides utilizar sólo parte de Scrum? Dejar de usar roles, eventos o artefactos tiene sus riesgos.

Apoya a tu equipo entendiendo qué le ocurre

La transparencia es uno de los pilares de Scrum. Con ella conseguimos hacer visible lo que ocurre dentro del producto, equipo, personas, … para hacer inspección y adaptación. ¿Cómo podemos saber qué ocurre en el equipo para poder apoyarle?

Es importante usar Historias de Usuario

Usar Historias de Usuario es importante para los Product Owner, además de la más utilizada a la hora de escribir el Product Backlog.

Beneficios de la automatización en los equipo Scrum

La automatización, cada vez más, forma parte del desarrollo del software. ¿Qué beneficios tiene para los equipos Scrum?

Multiplica los resultados de tu Sprint Planning

Hoy es día de Sprint Planning. Miras hacia tu equipo y… sólo ves pacas de paja rodar de un lado a otro. ¿Qué ha pasado con tus compañeros? ¿Dónde se esconderán? ¡Te han dejado solo! Te traigo 5 consejos para multiplicar los resultados de tu Sprint Planning.

Burndown y Burnup para el Scrum Master

Como Scrum Master puedes obtener información muy valiosa analizando estos dos gráficos para entender lo que está ocurriendo en tu equipo.

Ventajas de aplicar el Lead Time en los Equipos Scrum

En ocasiones, cuando arrancamos con los Equipos Scrum, nos encontramos con un par problemas habituales: el tamaño de los PBIs y que trabajan en paralelo en todas los PBIs del sprint. Hoy te traigo una solución que hemos puesto en marcha en algunos Equipos Scrum de nuestros clientes.

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Aceptarás nuestra política de cookies si continúas navegando.

ACEPTAR
Aviso de cookies