Las estimaciones son siempre un tema muy polémico en las discusiones sobre Agile. ¿Hace falta estimar? Mucho hemos hablado de ello, vamos a analizar si “estimar es Agile”, una frase que genera mucha controversia, y también analizamos la cultura “#noestimates”.
¿Estimar o predecir?
El movimiento #noestimates busca reducir o eliminar las estimaciones. Sin embargo, vivimos en un mundo donde nos gusta tener control del tiempo (o creer que lo tenemos). Confiamos en los expertos para que nos den una idea de lo que se tarda en hacer la tarea, o el precio final de lo que compramos.
La gran confusión radica en cómo hacerlo. Qué no estimes no significa que no hagas predicciones. Por ejemplo, en la meteorología no hay estimaciones, pero si hay predicciones. La diferencia recae en que, las predicciones se hacen a base de estadística y cada pronóstico se acompaña de una probabilidad. “Mañana hay un 80% de probabilidad de lluvia”.
Hay una idea que es importante que tengamos en consideración. En Scrum, y en Agile, podemos hablar de fechas, pero siempre que tengamos datos. Lo que no debemos hacer, es decir el tiempo o el coste en fases muy tempranas cuando el número de variables que no controlamos es muy elevado. Podemos crear una expectativa que genere mucha frustración. Cuando prometemos algo muy pronto, posiblemente nos equivoquemos y después, tendremos muchas conversaciones sobre por qué no se cumplió la fecha en vez de hablar sobre si los customers compran el producto o que faltaría para que lo hicieran.
¿Estimaciones ágiles?
El famoso libro de Mike Cohn sobre Planificación y Estimación Agile creo que ha hecho mucho daño a las personas que queremos promover un cambio. El libro propone trabajar con puntos de historia, y usar esa herramienta para predecir nuestro proyecto.
Este libro, asume que podemos saber de antemano todas las funcionalidades que queremos abordar y, por tanto, podemos controlar la desviación. Siendo los puntos de historia una buena técnica de estimación, sigue viviendo en el paradigma de estimar y controlar.
Una vez más, la propuesta de Mike Cohn parte de la base de que podemos conocer todo antes de empezar, y ese es quizás el gran problema de la mentalidad tradicional: tomar demasiadas decisiones antes de comenzar el trabajo.
La startup que resuelve problemas tiene éxito
Cada vez que leo sobre startups de éxito o que funcionan, todas tienen algo en común: se centran en su customer antes que en el dinero. Tienen claro que si resuelven un problema por el que alguien paga o que genera valor, podrán monetizarlo o conseguir un inversor que les de energía para seguir.
En la cultura latina, estamos más orientados a controlar el coste, no queremos pagar de más, y por eso queremos estimaciones tempranas y un férreo control. Quizás, por eso, tenemos pocas startups de éxito en comparación con países anglosajones.
El exceso de control afecta a nuestra capacidad de innovar, tenemos una ausencia de foco en lo que realmente importa.
Medir en vez de estimar
En Agile buscamos la toma de decisiones en base a métricas. Decidir qué queremos medir, inspeccionar frecuentemente los datos y adaptarnos. Eso es lo que promueve un agilista.
Medir supone entender qué métricas nos dicen si vamos por el buen camino. ¿Cómo sabremos en un mes que hemos tomado buenas decisiones o por el contrario tenemos que pivotar? Definir nuestras métricas es clave, y no solo aquellas relacionadas con el éxito de nuestro producto, sino aquellas que nos den pistas sobre el comportamiento de los customers. Por ejemplo, si tenemos un comercio online, las ventas nos dicen si vamos bien, pero estudiar cuantos usuarios nos visitan y cómo se comportan nos puede ayudar a descubrir features que no sirven u otras que hay que potenciar.
A nivel “productividad” de un equipo, podemos hacer predicciones de lo que un equipo será capaz de entregar, pero siempre midiendo la cantidad de software terminado por unidad de tiempo (o cantidad de trabajo si lo aplicamos fuera de la tecnología). Por ejemplo, medimos la cantidad de entrega en varios Sprints y utilizamos ese dato para hacer proyecciones sobre futuras entregas.
Hablar de fechas es importante, pero sin datos, todo quedará en opiniones, y, casualmente, siempre se impondrá la opinión del que tenga más “poder” en la conversación. Agile busca cambiar esas opiniones en forma de estimación por un modelo más empírico, basado en medir para decidir.
Y tú, ¿estimas o mides?
Hola Javi, me ha gustado mucho este articulo.
En Kanban medimos el cycle time y mantenemos estadisticamente una probabilidad que nos dice el tiempo minimo que el equipo tardara en entregar algo. El hecho de no “haber” iteraciones en Kanban nos ha ido bien ya que hacemos un forecast. Aun asi, creo que con Scrum, cuando trabajamos con SP pasaba lo mismo, de ahi no saber muy bien como interpretar el articulo. Si sabes de los ultimos X sprints la cantidad de SP por unidad de tiempo que el equipo ha sido capaz de entregar, no estas midiendo?
GRacias
El problema de medir SPs es que los SPs son muy subjetivos. Parten de una estimación, sí hecha en equipo y seguramente reflexionada pero no deja de ser opinión. Si mides el número de features que desarrollas es más científico porque mides a posteriori ti capacidad de entregar… Y nunca, esto es importante, busquemos la exactitud…