El mundo de las estimaciones es muy polémico. Hay una corriente en el mundo Agile a favor del #noestimates. #Noestimates no defiende que no se estime, sino que lo hagamos en base a estadística, que nos basemos en datos para tomar decisiones. En los inicios de Agile, se pusieron de moda técnicas como los Puntos de Historia y el Planning Poker, lo que conocemos como “Agile Estimation and Planning” que recogió en su libro Mike Cohn.
Sin embargo, si algo trae Agile es una manera diferente pensar, pasar de un modelo predictivo a uno adaptativo. Soy capaz de tomar decisiones en base a lo que realmente ocurre y no a lo que soy capaz de estimar. ¿Significa eso que no podemos trabajar con fechas en Agile? ¡Lo analizamos!
Hablemos de Caos
Los sistemas caóticos son aquellos donde la cantidad de elementos que entran en juego es tan elevada, que no podemos predecir lo que va a ocurrir. Por ejemplo, el tiempo atmosférico no es exacto porque depende de muchísimas variables, de ahí la famosa frase del aleteo de una mariposa en Brasil podría provocar una tormenta en Rusia.
Sin entrar en una clase de ciencias avanzadas, vamos a explicar un ejemplo de problema que no tiene solución y cómo actuamos en estos casos. Cuando estudiamos física básica en el instituto, nos enseñaron el típico problema de dos objetivos circulares que se atraían con una cierta fuerza simplemente por tener masa. Es decir, imagina dos cuerpos suspendidos en el vacío, se atraerán de la siguiente manera:
La fuerza con la que se atraen depende directamente de la masa de los cuerpos, e inversamente proporcional a la distancia. La G representa la constante de gravitación universal. Esto es un problema muy sencillo de física, dónde es cuestión de sustituir las letras por sus valores y obtenemos un resultado. ¡Sabremos lo que pasará!
Imagina que a este caso le añadimos un tercer cuerpo. A nuestra vista, parece mucho más sencillo que si tratamos de pensar en el universo con sus “infinitos” cuerpos. Sin embargo, en el momento que aparece el tercer cuerpo, entramos en el mundo del caos (desde el punto de vista físico). No podemos calcular lo que ocurrirá, al menos desde un punto de vista analítico.
Si en el Sistema Solar quitamos un planeta, entonces no sabremos las consecuencias que tendrá. Tendremos que esperar un tiempo a que el sistema se estabilice. La mejor aproximación es mediante inspección y adaptación. Es decir, esperamos un poco de tiempo, analizamos los resultados y tomamos decisiones (si se van a chocar dos planteas quizás sea buena idea huir de uno de ellos).
Los equipos de trabajo mayores de tres
En Scrum, recomendamos aplicarlo para equipos entre 3 y 9 personas. El número tres es porque, a partir de tres personas el número de interacciones entre ellas empieza a rozar el caos. En el trabajo del conocimiento, existen muchísimas variables que nos impiden calcular de manera analítica lo que va a ocurrir.
Sin embargo, hemos construido la industria del software en torno a las estimaciones. Nos dicen el trabajo que hay que realizar, lo que llamamos el alcance, y calculamos lo que nos va a costar en términos de tiempo y dinero.
En el mundo del conocimiento, y el software lo es, nos pagan por “pensar”. Obviamente, desarrollar software es el trabajo, pero hay muchas maneras de hacerlo, y los buenos developers son aquellos capaces de hacerlo de una manera genuina. Por eso, es complicado comparar un equipo con otro, y mucho menos tratar a las personas de “recursos” y pensar que las personas trabajarán igual.
Además, estamos en un mundo súper competitivo, el ser rápidos llevando soluciones a nuestros customer hacen que traigamos y retengamos el negocio. Por eso, es vital poner el foco en métricas orientadas a nuestro negocio y nuestra capacidad de generar valor (dinero en organizaciones con ánimo de lucro).
“Cuanto antes lo sepamos, mejor”
Hay una frase de “1º de Manager” que siempre se dice a la hora de estimar. Un equipo está estimando si llegarán a una posible fecha y el responsable dice “cuanto antes sepamos que no llegamos, mejor, así podemos tomar medidas”. Una vez, en un equipo que arrancaba una implantación de un producto, hicimos el siguiente ejercicio.
Calculamos que teníamos seis Sprints de dos semanas para acabar la implantación. En cada Sprint decidimos que debía entrar para poder llegar. Las cuentas no salían por ningún lado, así que, lo transmitimos al Product Owner y la Organización. La respuesta fue: “bueno es muy pronto, vamos a ir viendo”.
Esta situación es muy habitual, después, durante toda la vida del proyecto, dedicamos muchísimo tiempo en reestimar todo para ver si ocurre el milagro. Además, solemos estimar de manera optimista, como si no hubieran problemas, ¡y siempre los hay!
Después, cuando las prisas nos hacen acabar desarrollando un producto con muchos errores o nos pasamos de la fecha: ¿por qué ha pasado esto?
El equipo de Youtube
En el libro “Mide lo que importa” de John Doerr, podemos leer la historia del crecimiento de Youtube. Cuando Google compró Youtube, lo hizo porque se quedaron atrás con su aplicación Google Videos. La responsable vió que Youtube sería el futuro de la televisión. Además, decidieron que su principal métrica pasaría de ser el número de clicks, de anuncios y de ingresos por una métrica diferente: número de horas de visionado. Entendían que si las personas ven los vídeos hasta el final, es porque son más felices y generaría una mejor experiencia de usuario (obviamente esto genera ingresos).
Se pusieron un objetivo ambicioso de multiplicar por 10 el número de horas de visionado, llegando a los 1000 millones de horas diarias en cuatro años. Todos los días inspeccionaba esa métricas, e iban incorporando nuevas ideas en Youtube que les permitiera llegar a esas cifras. Toda su energía se iba en ella, y no tanto en si los equipos trabajan bien o si eran capaces de construir un software en fecha.
Tenían una fecha, pero como un reto, no como una métrica de rendimiento. Era una métrica de outcome, de ser capaces de generar valor en un producto para llegar a una cifra que se antojaba una locura.
Pero las fechas existen, no nos engañemos
Sería absurdo pensar que podemos trabajar “sin fechas”. Hace unos meses, estábamos trabajando con una empresa textil, y para ellos la semana más importante del año es el Black Friday. Le contábamos a la responsable de un área importante de negocio que, una cosa es no tener fecha, y otra obviar que existe el Black Friday. Las fechas que afectan a nuestro producto y su potencial negocio, debemos tratarlas de manera transparente, y “jugar” con la cantidad de funcionalidad que nos dé tiempo a tener terminada.
Por eso, es vital que haya transparencia en un equipo sobre el negocio, cómo ganamos dinero, cómo generamos valor y que fechas son vitales para conseguirlo. Una vez que todos partimos con la misma información, ¡tomemos decisiones!
En vez de tratar de estimar para “controlar el tiempo”, piensa en los retos que tienes por delante, cómo vas a medir si vas por el buen camino y transparentar las fechas. Cualquier startup joven sabe que la fecha más importante es el “time-to-tomb”, tiempo a la tumba. Esta métrica nos dice el tiempo que vida que nos queda, si antes no conseguimos crear un producto que atraiga dinero o inversión tendremos que cerrar. Hacer transparente esta métrica consigue que las personas se esfuercen en ese reto, en vez de ocultarlo para que las personas “no se asusten”.
Y tú, ¿estimas o transparentas?
