Desde casi los comienzos de este blog he hablado regularmente sobre el popular tema de la estimación, con posts que trataban enfoques más tradicionales (ya casi obsoletos), post sobre los enfoques más ágiles, post sobre cómo han evolucionado las técnicas y enfoques sobre estimación, de la no-estimación (#noestimates), etc. Hasta escribimos una guía, de descarga libre, en pdf sobre el tema.
Han pasado los años y, en general, siempre hay de todo, las cosas han evolucionado. Hace unos años, por ejemplo, era raro ver gente trabajando en Sprints, y tenía mucho sentido hablar de la necesidad de ciclos de vida iterativos e incrementales, etc., ahora hay más necesidad de hablar de cómo, aun usando Sprints, sigues colando un cascada (como este post y este otro), por ejemplo.
Y así con muchas cosas y también con la estimación ágil, antes era importante hablar de cómo la idea de «velocidad» podría serte útil y hoy de… cómo estás usando peligrosamente la velocidad… y de ahí este post.
En este post entiendo que ya sabes lo que es la velocidad en agilidad (si no puedes leer antes otros como este, que está dibujado), y lo que te quiero contar es algunas interpretaciones peligrosas, o falta de criterio, o comportamientos cuestionables, etc., que yo me encuentro después de ver, por suerte, en cierto modo, a tanto equipo usando la idea de velocidad ágil.
1 Trabajar de manera ágil no es hacerlo más rápido, cierto, pero eso no implica que la velocidad no importe o justifica trabajar lento
Trabajar de manera ágil no es hacerlo lo más rápido posible (a este tema ya le dediqué un post hace unos años), esto debería estar claro, la manera de trabajar más rápido (a corto, medio plazo) es haciendo «chapuzas», saltándose actividades que no tienen tanto beneficio a muy corto plazo y que se hacen para alegrarnos la vida después, como son, en software, el Testing, la calidad software, código limpio, integración continua, etc.
Pero ojo, cierto, el mensaje hoy de «agilidad no es hacerlo más rápido» ya ha calado pero cuidado, no caigamos en el otro extremo, que la agilidad no sea hacerlo «lo más rápido» no justifica ir lento o no buscar la mayor velocidad, concretamente…
2 El objetivo es máxima velocidad a «ritmo sostenible»
Trabajar de manera ágil no es hacerlo de la manera, a corto plazo, más rápida posible, cierto (eso sería condicionar el futuro y asumir que el futuro será más lento), pero eso no justifica trabajar lento o no preocuparse por la velocidad y en aumentarla lo posible, entonces… ¿en qué punto nos quedamos?
Hay una antigua práctica, el «ritmo sostenible» (sustainable pace), que ayuda a entender esto, es una práctica muy de eXtreme Programming (salvo descubrimiento de una referencia anterior, todos hemos asumido que origen está en eXtreme Programming), que también aparece en uno de los principios de manifiesto ágil, etc., que habla de que un equipo debería trabajar sin grandes picos de exceso de trabajo y sin grandes caídas.
Lo suyo, ya que descartamos medir picos o caídas en «horas» es medirlos en trabajo completado al final del Sprint (aunque también hay quien referencia el ritmo sostenible en límites de horas de trabajo semanales, las famosas 40 horas), que el ritmo de trabajo completado al final del Sprint sea en ese ritmo sostenible, sin grandes picos y caídas.
Entonces, lo suyo, ojo, es máxima velocidad a ritmo sostenible.
2. El secreto de la velocidad es la búsqueda, y eliminación, constante de desperdicios
Si la velocidad importa y deberíamos aumentarla hasta un, y mediante, ritmo sostenible sólo hay un camino por el que pasar, aquel que marca la diferencia, al que pocos equipos llegan, en el que no valen «postureos ágiles» ni jueguecitos vacíos… la búsqueda inteligente de desperdicios y su eliminación. Y ahí… hay que arremangarse, ser listo y saber de verdad que qué va esto. Para esto no vale cualquiera.
Aquí hay que saber seleccionar que supuestas buenas prácticas lo serán para nosotros, que Test, que tipo, dónde, nos ayudará más, que actividad estamos haciendo que no está aportando, qué automatizar, qué no, etc.
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
Con respecto a la velocidad de un equipo, sobretodo si se orienta a producto, creo que un aspecto clave es la herencia generada. Y lo leo entre líneas en el segundo punto que describes.
Se puede trabajar, sin hacer chapuzas, a mínimos. Es decir, cumplir las historias que nos han pedido y poco más. Pero… ¿Debemos invertir en refactorizar lo que nos vamos encontrando? ¿En crear test de regresión para que luego nos cueste menos probar los desarrollos futuros? ¿En crear herramientas de monitorización que nos ayuden luego a entender que está pasando cuando la ponemos en producción?
Esto es lo que yo relaciono con la velocidad sostenible. En no ir rápido ahora, generando un peso en el futuro. Si no nos quitamos los pesos, luego no mantendremos la velocidad.
Por cierto, tienes dos doses y te falta un tres 😉