Estimaciones en Kanban

Estimaciones en Kanban

Las estimaciones en Kanban son un tema candente. Mucha gente nos pregunta cómo estimar proyectos en Kanban. ¡Bueno, pues no lo hacemos!. Aprende cómo en este post.

Es curioso cómo en la era delBig Data, el Machine Learning y la IA muchas organizaciones siguen aplicando las prácticas de videntes y chamanes para tratar de predecir el futuro. Afirman que”usamos big data para comprender los comportamientos de los clientes” y yo les digo”Sí, y pides estimaciones a tus equipos de desarrollo. Qué bueno es eso :)”.

En Kanban utilizamos una alternativa simple pero poderosa a las estimaciones que se basa en datos y estadísticas.

El Mito de las Estimaciones

Hacer predicciones no aumenta la previsibilidad. No importa cuántas veces estimemos cuánto tiempo tardaremos en hacer algo, eso no afecta la capacidad del sistema. La previsibilidad es una propiedad del sistema y si no entendemos nuestro sistema no podemos predecir su comportamiento.

Las estimaciones, según las entendemos nosotros, son mediciones que se utilizan para reducir la incertidumbre de una decisión a tomar. Por tanto, lo primero que hay que tener claro es la decisión a tomar y luego saber un poquito de estadística y probabilidad. Esto lo explica muy bien Douglas W. Hubbard, en su libro “How to Measure Anything”.

Un Poco de Ciencia

Una cosa es estimar lo que una sola persona tardará en hacer algo, y otra muy diferente es estimar el tiempo que tardará a una Historia de Usuario desde el Commitment Point hasta la entrega.

Cuando alguien pregunta “¿Cuándo estará hecho esto?” Lo que realmente quieren decir es “¿cuándo estará en producción?”. Pero, nadie tiene la más remota idea. La gente está mintiendo o adivinando, o ambas cosas.

Hay varias razones por las que estimar es una pérdida de tiempo y es peligroso para tu negocio, porque estás tomando decisiones basadas en datos incorrectos. Puedes investigar más por ti mismo en los siguientes enlaces:

  • Teoría de la información: “El cono de la incertidumbre” – en el momento de realizar la estimación tenemos muy poca información y solo mejorará a medida que el proyecto avance. Esa es la razón por la que recomendamos el desarrollo iterativo e incremental y la financiación de proyectos.
  • Matemáticas: “Covarianza” – en una dependencia lineal de dos o más variables, la fluctuación de otras variables hacia abajo está determinada por la desviación máxima establecida por cualquiera de las variables anteriores.
  • Teoría de colas: el tiempo de entrega aumenta cuando la utilización de recursos es alta en un sistema con variaciones.
  • Lean: “Eficiencia de flujo”: la baja eficiencia de flujo típica de la mayoría de las organizaciones significa que la mayoría de los plazos de entrega están influenciados por factores ambientales. Como resultado, el tiempo de espera no es muy sensible al tamaño o complejidad de una característica única, ni a las personas específicas involucradas o sus habilidades.

Diferentes Enfoques sobre las Estimaciones

En lo referente a las estimaciones existen diferentes enfoques:

La gestión tradicional de proyectos hace una promesa basada en la triple restricción de alcance, tiempo y presupuesto. Después de una estimación y una planificación, se reserva un presupuesto y se acuerdan un alcance y un cronograma.

Agile no se realiza tal compromiso.Puede haber una fecha de entrega acordada en algún momento en el futuro, pero el alcance es flexible. Puede que exista una definición de alcance de alto nivel, pero los detalles finos evolucionan con el tiempo.

Kanban no hace ni una cosa ni la otra. No buscamos hacer una promesa y comprometernos basándonos en algo que es incierto.Una implementación típica de Kanban implica el acuerdo de que habrá una entrega regular de software de trabajo de alta calidad.

Kanban ofrece un compromiso con un nivel de servicio para cada clase de servicio, y un compromiso con la entrega regular fiable, la transparencia, la flexibilidad en la priorización y el procesamiento, y la mejora continua en la calidad, el rendimiento, la frecuencia de entrega y el tiempo de entrega.

¿Cómo funcionan las estimaciones en Kanban?

Bueno, tal como te he comentando anteriormente, en realidad no se realizan estimaciones en Kanban. Utilizamos previsiones probabilísticas. Pero, para hacer eso necesitamos diseñar y utilizar adecuadamente un Sistema Kanban.

Esto es así por dos razones fundamentales:

  1. Kanban se basa en que estamos en un sistema PULL, dónde no hay una planificación de la producción en lotes, sino que se produce según la demanda de los procesos que hay más adelante en el flujo de valor o en la demanda del cliente. Por tanto, lo que tenemos que conocer muy bien son las métricas de producción de nuestro sistema y las palancas para adaptarnos a las necesidades de nuestros clientes. Pero no planificamos.
  2. En la mayoría de las organizaciones los plazos de entrega están influenciados por factores ambientales (sistémicos). Como resultado, el tiempo de espera no es muy sensible al tamaño o complejidad de una característica única, ni a las personas específicas involucradas o sus habilidades.

Como decíamos, para poder hacer predicciones necesitamos diseñar e implementar un Sistema Kanban.

Diseña tu Sistema Kanban

Bueno, primero que todo, necesitas diseñar un sistema Kanban adecuado. Debes comprender la demanda, los límites del sistema, la entrega, los tipos de elementos de trabajo, las políticas de acuerdo, las clases de servicio, etc.

Para crear un sistema predecible, debes tener claro el punto de llegada y el punto de salida de su sistema. Dentro de estos límites es donde ocurre la magia.

Estimaciones en Kanban - Diseño Sistema Kanban - Upstream Kanban - Downstream Kanban - AKTIA Solutions

Adoptar Kanban

Debes adoptar las seis prácticas clave de Kanban que permitirán que tu sistema de entrega sea predecible en el tiempo. Puede utilizar nuestra Evaluación de Madurez de Kanban para comprender qué tan bien estás adoptando Kanban.

Comprender la Variabilidad

En Kanban podemos mejorar la previsibilidad al reducir las fuentes de variabilidad en nuestro sistema. Utilizamos el Diagrama de Flujo Acumulativo (Cumulative Flow Diagram), el Histograma de Lead Time y el Diagrama de Dispersión de Lead Time (o Gráfico de ejecución) para comprender qué tan bien está funcionando nuestro sistema y detectar áreas de mejora.

Cumulative Flow Diagram - CFD - Estimating in Kanban - Predictability in Kanban - AKTIA Solutions

Lead Time Histogram - Predictability - AKTIA SolutionsLead Time Scatterplot - Runtime Chart - AKTIA Solutions

La variabilidad es un mal necesario. Para innovar necesitamos variabilidad, pero no hasta el punto de que nuestro proceso sea completamente impredecible.

Queremos permitir cierto nivel de variabilidad en el Fuzzy Front End, pero no tanto en el proceso de desarrollo. Seguramente no querrás tener un proceso de implementación poco confiable, errores de producción frecuentes, tamaños de historia de usuario disparejos, una alta especialización individual en los miembros del equipo, demasiadas dependencias con otros equipos, colas por todas partes o pruebas de regresión manual.

Las fuentes típicas de variabilidad en los procesos de desarrollo son:

  • Internas:
    • Tamaño de los trabajos
    • Mezcla de tipos de trabajo
    • Mezcla de clases de servicio
    • Flujo irregular
    • Rehacer trabajos
  • Externas:
    • Tamaño del lote
    • Ambigüedad en los requisitos
    • Expedición de trabajos
    • Flujo irregular
    • Disponibilidad de los entornos de trabajo
    • Otros factores del mercado
    • Dificultad para programar actividades de coordinación
  • Seres Humanos

Estimaciones en Kanban = Previsiones

Las estimaciones en Kanban no se tratan de adivinar o usar una bola de cristal. Utilizamos pronósticos y estadísticas probabilísticas.

Dependiendo del contexto, después de 2-3 semanas de ejecución de Kanban, podrás comenzar a pronosticar trabajos individuales y proyectos completos.

Veamos cómo hacemos esto en las adopciones de Kanban.

Previsión de una Funcionalidad Individual

El problema que veo en la mayoría de las empresas con las que trabajamos es que, debido a la falta de comprensión de la capacidad de su proceso de desarrollo, siguen empujando cosas hacia la línea de desarrollo con la esperanza de que se haga con el tiempo. Lo que no se dan cuenta es que al hacer esto se vuelven más lentos, las personas se estresan y la deuda técnica se acumula.

A menos que pongas algunos datos enciman de la mesa basándote en un sistema predecible, no podrás terminar este círculo vicioso de stakeholders pidiendo estimaciones, mentir a los equipos de desarrollo y empujar muchas cosas para que algo se acabe haciendo eventualmente. Lo que estás haciendo es crear un sistema más lento e impredecible que a su vez hace que los stakeholders empujen más cosas en un bucle infinito.

Cuando lleves usado Kanban correctamente durante 2 o 3 semanas, podrás obtener un histograma de tiempo de entrega. Esta es la herramienta que utilizaremos para proporcionar un pronóstico preciso.

Normalmente utilizamos un percentil del 85% para tomar decisiones de programación.

Lead Time Histogram - Predictability - AKTIA Solutions

Si comenzamos demasiado pronto, sacrificamos la oportunidad de hacer otra cosa que pueda aportar valor. Si comenzamos demasiado tarde, corremos el riesgo de incurrir en el coste de la demora (Cost of Delay).

Si incorporamos la nueva funcionalidad a nuestro sistema Kanban el 1 de abril, tenemos un 85% de probabilidad de entrega a tiempo. El 1 de enero, el item estará disponible para su selección en la reposición del sistema Kanban (Replenishment). El momento ideal para comenzar es el 1 de abril. Después del 10 de mayo, nuestra opción de entregar este elemento caducará y lo descartaremos de nuestro backlog.

Por lo tanto, estas son las preguntas inteligentes que debes hacerte:

  • ¿Deberíamos comenzar este artículo ahora o podemos esperar y hacer algo de mayor valor para el cliente o la organización?
  • ¿Es demasiado tarde para comenzar este desarrollo?
  • ¿Cuál es la cantidad de riesgo que podemos asumir con este elemento? 85%, 90%, 95% o ¿deberíamos comenzar lo más pronto posible sacrificando otras opciones?
  • ¿Cuál es el coste semanal de retraso de esta funcionalidad (Cost of Delay)?

Previsión de Multiples Funcionalidades (Proyecto)

En su sitio web Focused Objective, Troy Magennis tiene muchas herramientas excelentes para monitorizar y predecir el desarrollo de software. Este sitio es un pozo de sabiduría y contiene muchos recursos excelentes de forma gratuita.

Esta herramienta te permite pronosticar cuánto tiempo tardará una sola funcionalidad o proyecto usando Agile o Kanban y Simulación de Montecarlo. Calcula probabilidades basadas en tus datos históricos.

Sé lo que estás pensando, “¿qué sucede cuando el equipo o el producto es nuevo y no hay datos históricos?”. Bueno, es fácil. Por ejemplo, puedes hacer lo siguiente:

  1. Puede comenzar desglosando tu alcance en todo el trabajo a realizar, utilizando una herramienta como User Story Mapping.
  2. Determinar en base a tu experiencia, sabiduría o proyectos anteriores un rango de incertidumbre en el rendimiento. ¿Cuántas historias dirías que tu equipo puede hacer por semana? Definir un mínimo y un máximo.
  3. Introducir esos datos en una herramienta de simulación de Montecarlo y tendrás una distribución probabilística con fechas
  4. Iterar y actualizar