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.

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?

En que punto del proceso consideramos el Producto como Entregable

Escoger dentro de nuestro proceso de generación de producto entregable el punto adecuado, puede ser muy complejo cuando dependemos de terceros.

¿Es conveniente tener un Equipo Scrum en exclusiva para Incidencias?

En tus Equipos Scrum os encontráis en una situación en la que la cantidad de incidencias que hay que atender os penalizan demasiado, o la deuda técnica acumulada aumenta en exceso la complejidad de cualquier evolución en software.

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.

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.

¿Tiene mi equipo Scrum los conocimientos necesarios para construir mi Producto?

Scrum propone que nuestros equipos tengan todos los conocimientos para generar productos que cubran nuestras necesidades. Te traigo hoy una herramienta sencilla para averiguar si tus equipos Scrum son realmente multidisciplinares.

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.

Definition of Ready y Definition of Done

¿Qué necesitas para poder comenzar una tarea? ¿Cuándo podemos dar una tarea por terminada? Para resolver estas dudas, en este vídeo te traemos el Definition of Ready y el Definition of Done

Cómo facilito una retrospectiva si no soy Scrum Master

Una buena retrospectiva da la oportunidad al equipo de analizar su funcionamiento y establecer mejoras. Te dejamos consejos para facilitarla.

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?

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