Sobre Roadmaps, planificaciones a medio – largo plazo, en gestión Ágil te he hablado muchas otras veces. Por ejemplo, hace unas semanas en algunas consideraciones sobre la Release Planning en Agilidad, hace un año en sobre Roadmaps ágiles, una visión a largo plazo sin comprometer el cambio o en aquel de cómo crear Cascadas y Proyectos, fácilmente, con Jira Ágil Portfolio.
Este no es un tema sencillo y hay que tratarlo con cuidado para no caer en el Lado Oscuro. Por un lado es razonable que, sobre todo en empresas medianas o grandes, se requiera de una planificación a unos meses, quizá a un año, pero… eso lleva en muchos casos a fijar fechas y alcance, es decir, nos lleva a lo que sería algo similar a un cascada o nos lleva a un proyecto cerrado.
Como te conté en este post, a diferencia del proyecto cerrado, en agilidad, normalmente, ojo, que no necesariamente, hay fechas, existe la iteración, que es un trozo de tiempo «time-box» con un final, mientras que el alcance, lo que se hará, es variable. Incluso en modelos de gestión tipo Scrum, el alcance del Sprint se asume que no va a variar una vez que se arranca el Sprint (se puede cambiar, pero no es la idea).
Pero, en cualquier caso, la variabilidad del alcance, lo que se hará, el cambio, es una idea clave en una gestión ágil… «Responding to change over following a plan» (como dice el propio Manifiesto Ágil).
¿Un Roadmap por naturaleza ya no es Ágil?
Entonces… ¿Un Roadmap por naturaleza ya no es Ágil? Complicada pregunta, porque hablamos de fijar qué se pretende entregar y cuándo, por ejemplo, en 6 meses. Y muchos Roadmaps Ágiles se hacen así (un ejemplo de ello son los Release Train de SAFe), se fijan fechas y se cierra alcance.
Si somos rigurosos con los valores Ágiles, realmente, cerrar un alcance, qué se pretende entregar en cierta fecha, no es «anti-Ágil» por naturaleza (aunque pueda contener mucho desperdicio, luego hablamos de ello), lo que sería «anti-Ágil» es que ese alcance no se pueda cambiar. Que no exista la cultura del cambio, que el alcance sea un contrato inamovible, que el cambio se vea mal, que se asocie con error en vez de con aprendizaje.
Por ello, los Roadmaps pueden ser una puerta al Lado Oscuro.
Si la cultura es sanamente Ágil no tiene por qué ser así, el alcance cambia sin problemas, pero si, por ejemplo, tus clientes no saben nada de esto y ven fechas y lo que se espera entregar en ellas… puede hayas despertado al Kraken. Puede que no entiendan que haya cambios según lo acordado, etc., y estaríamos en lo de siempre (proyecto cerrado, ¿el peor enemigo del software o mal necesario?).
El desperdicio de los Roadmaps
Otro tema interesante, que te mencioné antes, es el del desperdicio que puede conllevar un Roadmap. La búsqueda y eliminación de desperdicios, cosas que no aportan valor, suena muy Ágil (idea heredada de Lean, «primo» cercano de la Ágilidad).
Invertir mucho tiempo y recursos en definir un qué esperamos tener a medio – largo plazo y que aquello que definimos como entrega futura cambie… es haber desperdiciado tiempo en hacer aquella previsión. Se ve claro. Y tenemos la responsabilidad de buscar y eliminar desperdicios.
Lograr un equilibrio es complicado, poder hacer previsiones de qué se entregará en un tiempo, mantenerse Ágil, y hacerlo con el mínimo desperdicio (ojo, siempre está la opción, si te lo permite tu negocio, de que no necesites un Roadmap y vivas «Sprint a Sprint»).
Dependerá de cada situación, pero lo que te puede ayudar a controlar el desperdicio es hacer previsiones lo más cortas posibles (piensa en MVPs), a mayor alcance temporal más probable es que cambie lo previsto. Y que, como te conté en sobre Roadmaps ágiles, una visión a largo plazo sin comprometer el cambio (y en la imagen de más abajo), que el nivel de abstracción en el que expreses ese «qué» sea mayor cuanto más lejano esté en el tiempo.
Escribir las 500 historias de usuario que se supone que tendremos en 6 meses, aunque tu cultura sea de cambio y estemos de acuerdo en que esas historias pueden cambiar, suena muy raro, conlleva un montón de desperdicio escribir todo eso, gestionarlo, priorizarlo, cambiarlo, etc.
Terminando
Al final la cultura es todo, la misma práctica usada en dos sitios diferentes, uno con cultura Ágil y otro no… crea escenarios totalmente diferentes. Pero, cierto es, que la vida es dura, y que tu puedes ser muy Ágil y tus clientes no, y que ellos te pidan un Roadmap y quieran fechas y alcance, entonces vas a tener que trabajar en culturizarlos para que te dejen ser Ágil.
También hay alternativas, dale vueltas al cerebro, frente a no tener roadmap o tener Roadmpas con fechas, hay quien usa Roadmps tipo Kanban, flujo continuo, sin fechas o meten una columna de «siguiente», otra «corto plazo» y otra de «largo plazo», para tener previsiones sin tener que poner fechas.
El Roadmap, por definición, puede encajar en la gestión Ágil si la cultura es Ágil. Otro tema es que tienes que minimizar los desperdicios que conlleva usar, o no usar bien, un Roadmap.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024