Stakeholders, esos, a veces, grandes olvidados y grupo desfavorecido

Stakeholders, ya sabes, todo aquel que no es ni Scrum Master, ni Product Owner, ni es parte del equipo técnico, y que suelen ser gente de negocio, comerciales, jefes de proyecto, etc.
Stakeholders, los hoy grandes incomprendidos (y con razón), y que antes, en la era pre-ágil, campaban a sus anchas, estaban ahí siempre, encima, con contacto y canal directo hacia los equipos, cuando ellos lo requerían. Pero, en algún momento, alguien los etiquetó como «el rol secundario» (también con razón), y que, desde ya, si queríamos «ser ágiles», los Stakeholders no hablarían con los equipos, harían de «secundarios» y su canal sería sólo el Product Owner, bajo la escrupulosa vigilancia del Scrum Master.
¿Hemos caído con el tiempo en una acción de discriminación positiva de los equipos técnicos frente a los Stakeholders? ¿Nos hemos llegado a pasar con los Stakeholders hasta el punto de casi darle la vuelta al modelo y que ahora sean ellos el grupo desfavorecido?
Lo de blindar a los equipos frente a los Stakeholders tuvo sus razones de peso, los pobres equipos tenían múltiples jefes, múltiples interrupciones, múltiples prioridades, múltiples cambios de prioridad, etc. Y sabíamos que trabajar en más de una tarea (ya no digo proyecto) a la vez genera perdidas de tiempo y disminuye la productividad, que interrumpir a quien programa, o al que realiza cualquier actividad intelectual, hace que su productividad caiga (mas de lo que imaginas), etc. De ahí vino la idea de controlar los canales y prioridades hacia los equipos técnicos.
Pero, después de muchas transformaciones ágiles… ¿qué tenemos hoy en lo que refiere a los Stakeholders? Pues lo que yo cada vez me encuentro es que se han convertido en un grupo marginal al que, y te dejo algunas frases literales que me cuentan, «no nos dejan ver nada», «no sabemos cómo van los proyectos», «no tenemos visibilidad», «no tenemos ni voz ni voto en nada», «enseguida nos regaña el Scrum Master», «me dicen que en agilidad no hay fechas» (ya sabes, aquello de “En agilidad no hay fechas y no se sabe cuando se termina”), etc.
¿Nos hemos pasado con los Stakeholders? Yo creo que, en algunos sitios, un poco sí.
Creo que en algunos sitios hemos talibanizado la agilidad, bueno, más concretamente, hemos talibanizado Scrum. Incluso creo que nos lo hemos leído un poco a medias y nos hemos quedado con lo que nos interesaba y así se lo hemos contado a los pobres Stakeholders. Si nosotros hay veces que aplicamos Scrum de aquella manera… peor lo tienen los Stakeholders, qué muchos no saben ni de que va (cosa que, en mi opinión, creo que es un error por su parte, que aun siendo Stakeholders deberían conocer la agilidad como el que más, mas si está cambiando su manera de trabajar y la de su empresa).
Que los Stakeholders tuvieran que pasar por un Product Owner no significa que estén excluidos completamente del modelo, que no participen en ningún punto.
Fíjate, y esto es sólo un ejemplo, que no quiero alargar el post, que si nos leemos la guía de Scrum, el tan mentado Scrum, si nos la leemos, leyendola sin hacerlo a salto, incluso leyéndola, hay por ahí una reunión llamada «Sprint Review» de la que se dice (creo que no es necesaria traducción):

«During the Sprint Review, the Scrum Team and ->stakeholders<- collaborate about what was done in the Sprint.»

Y también que:

«Attendees include the Scrum Team and key stakeholders invited by the Product Owner»

De hecho, como te conté en interiorizando el significado del Dual-Track, el Sprint Review no es tanto el Product Owner… es para la colaboración del equipo y los Stakeholders.
Y lo del Sprint Review es sólo un ejemplo, de entre todo «el mar ágil», que va más allá de sólo Scrum. Pero que sirva este post para que aquello de «colaboración» involucre también a los Stakeholders.

2 comentarios en “Stakeholders, esos, a veces, grandes olvidados y grupo desfavorecido”

  1. Los stakeholders son la parte más importante en la gestión del producto. El product owner debería trabajar pensando en ellos como el cliente. Si tenemos un equipo del que los stakeholders se quejan de que no les dan visibilidad, no les dejan opinar, y que no saben cuándo estará.. ¿De qué sirve la agilidad?
    Tenemos equipos que se miran el ombligo y no atienden a negocio.
    ¿Alguien me puede explicar que diferencia hay entre un desarrollo con una entrega al final del proyecto y uno iterativo en el que los stakeholders no ven como va avanzando?
    Desde mi humilde punto de vista el 75% del tiempo del product owner debería estar enfocado en la gestión de stakeholders. ¿Están contentos? ¿Vamos en la dirección correcta? ¿El backlog está priorizado como toca?
    El product owner no puede definir prioridades, sin tener en cuenta a los stakeholders. Si no, serán las prioridades personales, y no las de negocio.

Deja un comentario

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

Share This
Ir arriba