¿Por qué no se estima en Kanban?

Las estimaciones son siempre polémicas dentro de los equipos y las empresas. De alguna manera, necesitamos asegurar a alguien cuándo acabaremos el trabajo (clientes, management, gerencia…) Nos turba tener un equipo que no sepa cuando acabará, cuando se cumple. Disponer de una estimación nos da sensación de control, aunque no nos da verdadero control. 

Sin estimar no sabemos gestionar

Hoy en día, parece que el 90% del trabajo de un manager consiste en la gestión, directa o indirecta, de las fechas. Son como maestros del tiempo. En primer lugar, la primera fecha es clave. Reunimos al equipo y le pedimos que nos digan cuánto tardarán, en algo que no han hecho nunca o que sabemos que sufrirá muchos cambios. Es complicado saber lo que se tarda en hacer algo que evoluciona con el tiempo. 

Después, hay que gestionar dicha fecha, estudiar desviaciones, incorporar personas al equipo, hacer horas extra o negociar el alcance con el cliente para que eliminé requisitos. Esta manera de funcionar es la establecida y, por desgracia, genera mucha frustración en la mayoría de personas que se dedican al software:

• los equipos lo detestan, están más tiempo reportando que trabajando
• Los mánagers acaban quemados de gestionar personas para que cumplan tiempos que dieron cuando no sabían de qué iba el trabajo
• Los clientes sufren retrasos y se pierden al no entender porqué no está aquello por lo que pagaron tanto

¡la industria sufre!

Estimar o Predecir

Sin embargo, hay otros hechos cotidianos que nos acompañan y no utilizan la estimación como herramienta. En la predicción atmosférica se basa en datos para dar un resultado, pero daros reales y nunca exactos. Las variables que intervienen en el clima son tantas, que necesitaríamos diez meses para calcular el tiempo que hará mañana. Sin embargo, usando los datos más relevantes, renunciando a la exactitud y dando intervalos de confianza. ¿y si hiciéramos lo mismo en el desarrollo software o, incluso, en cualquier problema complejo?

Para ello, es clave jugar con las mismas reglas. Es decir, renunciar a la exactitud, utilizar datos del equipo y dar predicciones con rangos. ¡Kanban ya lo hizo!

Predicción estadística con Kanban

El método Kanban fue ideado por David Anderson en 2005, basado en sistemas kanban de Toyota. En las industrias, podemos definir un proceso de trabajo y medir multitud de parámetros que nos habiliten para ser predecibles: cantidad de coches que producimos en un periodo de tiempo, tiempo en producción un coche, número de errores, veces que cumplimos nuestros tiempos de entrega… 

El método Kanban se ideó para el mundo del conocimiento y utiliza la misma aproximación. Si tengo tareas parecidas, puedo medir el tiempo que tardó en realizarlas y, con estos datos, dar una predicción. 

Sí, en el mundo industrial se intenta reducir la variabilidad, mientras que en el mundo del conocimiento disponemos de mayor heterogeneidad. Aún así, siempre podemos medir lo que tardamos en hacer el trabajo y, con ello, estudiar mecanismos de mejora. Y, recordad, no buscamos la exactitud, sino nuestro capacidad de entrega en el tiempo con intervalos. 

El equipo indio que trabajaba estimando

El primer equipo que aplicó el método Kanban estaba en la India trabajando para Mircrosoft. Este equipo realizaba, básicamente, dos tipos de trabajo: errores (Bugs) y desarrollos pequeños (inferiores a 14 días). Sin embargo, al introducir el método Kanban, se dieron cuenta que había un tercer tipo de trabajo: estimar. Invertían mucho tiempo en estimar cada uno de los items, lo que hacía que el equipo pasara mucho tiempo en adivinar el futuro, en vez de estar trabajando sobre los problemas que les pedían sus clientes. 

Para mejorar esta situación, decidieron hacer explícito las estimaciones como parte del trabajo. Los datos fueron demoledores, casi un 30% del trabajo se dedicaba a estimar ¡Esto reduce nuestra capacidad de entrega!

Gracias a esta medición, se eliminó las estimaciones del equipo. A partir de ese momento, las predicciones se harían basada en datos reales sacados del equipo. 

¿Cómo sabían que una tarea era inferior a 14 días si no estimaban? En vez de hacer un análisis de todas las tareas, cambiaron de estrategia. Cuando un desarrollador arrancaba un nuevo trabajo (item) rápidamente descubría el tamaño, sobre todo al compararlo con el trabajo de los últimos meses. Con eso, se podría descartar aquello que fuera a ser demasiado largo. 

Refinamiento para ser más predecibles 

Por tanto, si queremos ser predecibles, necesitamos cierta homogeneidad en los trabajos que haremos. Esto significa trabajar sobre las tareas, es decir, dividir aquellos trabajos grandes y unir los pequeños. 

Este concepto Scrum lo denomina refinamiento. En Scrum se crean reuniones entre Product Owner y Developers para trabajar los items futuros y que se parezcan. En Kanban es diferente, explicitamos los pasos que necesitamos antes de trabajar y esto nos sirve para dejar el trabajo refinado. En ambos casos, tenemos que ser capaces de nutrir al equipo de trabajo y no paralizarlo.

En equipos waterfall invertimos mucho tiempo en analizar el problema y paralizamos el desarrollo, esto no es válido en Agile. Debe convivir el desarrollo con el refinamiento.

Y tu, ¿Estimas o usas datos?