En mi experiencia de años, en esto de ayudar a equipos y organizaciones hacia una gestión Ágil (en ocasiones con éxito, en otras no), hay un cambio que, aparentemente, debiera ser algo simple de interiorizar, pero que suele provocar tremendos problemas y frustraciones si no se acaba entendiendo: tener claras las responsabilidades de cada rol, típico, en agilidad.
Este no es un tema nuevo, por supuesto, ni del que escriba por primera vez. Hay varios post en el blog (como estos dos muy antiguos, de 2014, de Derechos y deberes de los miembros de un equipo ágil y el de Una infografía (en español) sobre el rol del Scrum Master o, más reciente, este vídeo).
Y más allá del blog, puedes leer sobre roles y responsabilidades en Agilidad en la guía de Scrum, en eXtreme Programming, en no sé cuántos libros que hablan de los roles y responsabilidades en agilidad, etc.
Pero a lo que voy hoy es que creo que en esa difusión de algo tan fundamental… hemos fallado.
Y creo que quizá hemos fallado por perdernos, y perder a la gente, en detalles, en listados de responsabilidades, en vez de haber dejado claras dos cosas: (a) en muy pocas palabras qué se espera de cada rol y (b) la importancia que juega el equilibrio entre los intereses de cada rol.
Para explicar lo anterior, de entre las n-mil referencias que podría usar, voy a rescatar una muy viejuna, del 2012, con la que me identifico mucho. Es aquel vídeo de Kniberg, del que te he dejado abajo una captura con la parte que nos interesa.
En muy pocas palabras, sin entrar en grandes listados, nos recuerda que…
- La responsabilidad primordial de un Product Owner es que se haga lo correcto.
- La responsabilidad primordial del coach del equipo, del Scrum Master, o como cada uno lo llame, es que se haga rápido (velocidad a ritmo sostenible).
- La responsabilidad primordial del equipo de desarrollo es que se haga de manera correcta.
Y, como segunda reflexión, que esto va de un juego de responsabilidades que busca un equilibrio entre las tres anteriores.
Como no hay un jefe, como antiguamente, que imponga sobre el resto, lo que buscamos es que los intereses de cada rol acaben en un punto intermedio.
Que si, por ejemplo, el equipo busca la perfección a la hora de crear algo, eso se vea compensado por que el «coach» busca la velocidad. Y al revés, que si el «coach» sólo busca la velocidad el equipo compense haciendo las cosas bien.
Tenéis que entender esto para evitar frustraciones y equívocos, para que además de entender el rol, por ejemplo, un Scrum Master entienda que el equipo tiene otros posibles intereses y que, como en otras tantas cosas en agilidad (esto me recuerda a la toma de decisiones en auto-organización), cada uno tiene una parte de la realidad y que buscamos ese equilibrio que suele dar mejores resultados.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- OKRs sin Lado Oscuro, IA para OKRs y alternativas para evaluarlos - 25 julio, 2024
- Por qué seguimos usando técnicas ágiles anticuadas: Efecto Einstellung - 18 julio, 2024
- Cómo crear una IA personalizada (me llevó meses, pero te lo enseño en 2 min) - 11 julio, 2024