La primera vez que escuché que sería posible lograr más si hacíamos menos cosas simultáneamente, me sentí escéptico. No tiene sentido, pensé.

Si tienes tiempo ahora, intenta hacerlo: escribe la secuencia A B C D E F G H tres veces, cada una en una línea diferente. Repítelo una vez, pero en el segundo intento, escribe primero todas las letras A, después las letras B, y así sucesivamente. Si mediste ambas pruebas, es probable que la primera haya terminado más rápido que la segunda. En mi caso, dos segundos menos.

Lo sé: el plazo de entrega es sólo un 7% menor. Pero imagina lo que podría suceder al desarrollar funciones complicadas en productos digitales, por ejemplo. O intenta hacer el mismo desafío escribiendo múltiplos de 3, 6 y 7 en cada línea hasta el décimo valor. Yo también lo hice: Un 21% menos (59 y 75 segundos).

Pero también tenemos otro punto importante: en la primera prueba, entregué el scope dividido en tres partes, quizás en nueve segundos cada una. Pronto se proporcionó algo de valor y pude recopilar comentarios y mejorar mi segunda entrega (segunda línea). Si entregas todas las líneas juntas (escribiendo todas las letras A, después de las letras B, etc.), tu respuesta será más lenta, los riesgos serán más importantes y el tiempo de entrega (plazo de entrega) será mayor.

Conceptos similares fueron explorados desde mediados del siglo pasado. Taiichi Ohno, considerado el padre del Sistema de Producción Toyota, escribió sobre un límite superior para el trabajo en progreso como una de las propiedades kanban en su trabajo para mejorar la eficiencia de fabricación. John Little (MIT, 1961) desarrolló la Ley de Little para explicar la relación entre el número promedio de elementos en un sistema de cola con otras dos variables. Ambos son buenos ejemplos.

En los últimos años, en el desarrollo de software, he experimentado una mejor comprensión de la relación entre lo que hacemos al mismo tiempo, con el tiempo para entregar esas cosas y el volumen de entrega. David Anderson reportó un caso interesante en su libro llamado Kanban (2011). En el estudio de caso presentado, afirma que existe una relación lineal de causa y efecto entre la cantidad de trabajo en progreso y el tiempo promedio de entrega.

En Nubank, mejoramos continuamente nuestros métodos y prácticas de trabajo. Obtuvimos un resultado impresionante en el siguiente ejemplo de un equipo de ingeniería de software:

En el primer gráfico, la línea verde muestra el promedio móvil del tiempo de entrega (para días laborables), considerando las últimas cinco historias de usuario completadas. La línea gris es sólo una proyección. Los puntos rojos son demandas en curso.

El segundo gráfico muestra la cantidad de demandas completadas por semana (con colores separados por tipo de problema). Ese es nuestro rendimiento.

El tiempo de entrega y el rendimiento son dos variables importantes que se deben medir en el desarrollo de software. Como podemos observar en el ejemplo, la media móvil es más estable desde el centro del primer gráfico hacia la derecha. En el mismo rango del segundo gráfico, la cantidad de entregas es mayor. ¿Cómo conseguimos disminuir el tiempo necesario para cumplir con nuestras demandas (tiempo de entrega) y aumentar la cantidad de artículos completados por semana (rendimiento)?

Check our job opportunies

Hicimos dos cosas “simples”:

  • Empezamos a gestionar mejor nuestro trabajo en curso (elementos en curso). Teníamos 4 del límite superior de demandas en el paso «Listo para Desarrollo» y 6 en todos los demás pasos antes de «Completado» en nuestro kanban (pasos «En Desarrollo», «Revisión de Código», etc.). Usando un tablero simple, limitamos una parte inicial del flujo para evitar que nuestras demandas se volvieran obsoletas y pasos de desarrollo para evitar hacer muchas cosas simultáneamente, estimulando a los miembros del equipo a ayudarse entre sí. Probablemente esas acciones ayudaron a estabilizar el promedio móvil del tiempo de entrega;
  • Disminuimos el tamaño de las demandas. Las cosas menores son más fáciles de entender y refinar, quizás más rápidas de entregar, con un alto potencial para brindar valor a nuestros clientes más rápidamente y recopilar comentarios más rápido sobre la entrega o las nuevas funciones. Eso podría explicar el aumento del rendimiento. Pero estamos entregando cosas más pequeñas y no programando más rápido; es importante decirlo.

¿Por qué hicimos eso?

Quizás sea una buena idea gestionar mejor tu flujo de trabajo si necesitas tener cierta previsibilidad. Por ejemplo, puedes alinear mejor las expectativas sobre las fechas de entrega si tienes un flujo de trabajo más estable y predecible.

También lo hicimos para mejorar la visibilidad de nuestro flujo de trabajo para verificar posibles cuellos de botella y mejorar nuestros métodos ágiles utilizando datos basados en nuestro comportamiento laboral. Creo que también puedes hacerlo para eliminar la sensación de parto lento.

Finalmente, como escribí anteriormente, estas prácticas pueden ayudarte a obtener comentarios más rápido, los riesgos pueden ser más fáciles de gestionar y el tiempo de entrega será más corto (esperamos).

Si empezamos a hacer algo, cualquier otra cosa que hagamos al mismo tiempo probablemente pueda competir con lo primero. Cuidado: no necesariamente necesitamos hacer solo una cosa a la vez, porque a veces podemos iniciar una segunda o tercera demanda mientras esperamos que algo indirecto suceda en la primera (por ejemplo, migración de datos de cuatro horas en tu Base de Datos, o una revisión de un compañero de trabajo en tu pull request).

Sin embargo, cuando termine esa primera cosa indirecta, tendrás dos o tres cosas que hacer simultáneamente y cada demanda competirá entre sí. Puede aumentar el tiempo de entrega, disminuir el rendimiento… está bien. Ya conoces la historia.

Recuerda la filosofía de Lean: Deja de empezar y comienza a terminar.

Check our job opportunies