Una historia de lead time en el área digital

Hace tres meses, Michael Ballé nos visitó en Theodo y, una vez más, nos preguntó dónde podía ver el plazo de entrega de nuestros productos digitales. Avergonzados, respondimos: “Bueno… eh… ya sabe, en realidad es muy difícil ver cuánto tiempo lleva, porque…”. Realmente no teníamos un buen motivo para no medirlo.

En Theodo, creamos e implementamos aplicaciones web para nuestros clientes. Las empresas acuden a nosotros cuando necesitan un equipo técnico para construir rápidamente su aplicación. Para iniciar un proyecto, tenemos que convencer a nuestros clientes de que entregamos valor más rápido que los demás. ¿No es ese un buen motivo para medir qué tan rápido entregamos?

DEFINA QUÉ Y CUÁNDO MEDIR

Antes que nada, permítame darle un poco de contexto sobre cómo trabajamos. Día tras día, nuestros desarrolladores construyen lo que está escrito en una tarjeta de Trello - lo que llamamos historias de usuario. Representan la parte más pequeña de una funcionalidad que puede enviarse, y no pueden tardar más de un día en crearse. Un grupo de historias de usuario constituye una épica, que representa una funcionalidad completa. A su vez, un proyecto está compuesto por varias épicas.

Por ejemplo, una épica podría ser: “Como vendedor, puedo enviar una factura al cliente por su pedido”. Y una de las historias para lograrlo podría ser: "Como vendedor, en la lista de pedidos del cliente, cuando hago clic en el botón 'Enviar factura', visualizo la factura antes del envío".

El lead time es el tiempo entre el momento en que usted recibe un pedido de un cliente y el momento en que se le entrega. En nuestro entorno, los clientes solicitan aplicaciones sin saber exactamente cuáles serán sus componentes; luego, semana tras semana, agregan épicas. Finalmente, deciden cuándo empezar a construir esas funcionalidades, y el equipo crea historias para esa épica.

Por lo tanto, nuestro problema inicial era entender qué lead time debíamos seguir. ¿Deberíamos centrarnos en el lead time del proyecto? ¿En el lead time de la épica? ¿O en el lead time de las historias de usuario? No logramos elegir, así que decidimos rastrearlos todos, definiendo cada uno de la siguiente manera:

• El lead time de un proyecto comienza en el primer contacto con el cliente y termina cuando la primera funcionalidad se lanza públicamente.
• El lead time de una épica comienza cuando el responsable del producto crea la épica y termina cuando la última historia de usuario de la épica se lanza a producción.
• El lead time de una historia de usuario comienza cuando se crea y termina cuando se libera a producción.

Empecé a trabajar con mis colegas Frédéric y Grégoire (ambos son desarrolladores líderes en distintos proyectos) en los dos últimos lead times. Frédéric se concentró en el lead time de las historias de usuario de su equipo, mientras que Gregoire se propuso entender el tiempo de espera de las épicas de su equipo. Nuestros primeros resultados mostraron que tardábamos entre 27 y 86 días en entregar épicas y entre 1 y 43 días en entregar historias de usuario.

¿HAY UN PROBLEMA QUE RESOLVER?

En ese punto, nos preguntamos si teníamos o no un problema entre manos. Sin un estándar claro, no podíamos decir si esas cifras eran malas o no. Entonces, tanto Frédéric como Grégoire se pusieron a definir el lead time que creían que debíamos buscar y confirmaron con el cliente que eran aceptables.

Frédéric aprendió que el plazo de entrega ideal para las historias de usuario es de menos de 10 días:

• 7 días en la fase de análisis: entre la creación y la primera línea de código.
• 1 día en la fase de desarrollo: entre la primera y la última línea de código de la historia de usuario.
• 1 día en la fase de validación: entre la última línea de código y el momento en que el responsable del producto valida la historia de usuario.
• 1 hora en la fase de implantación: desde la validación hasta que la historia de usuario se implanta en línea.

Descubrimos que 7 historias de usuario de un total de 19 estaban retrasadas:

• 5 tardaron más de 7 días en la fase de análisis.
• 3 tardaron más de 1 día en la fase de desarrollo.
• 3 tardaron más de 1 día en la fase de validación.
• 18 tardaron más de 1h en la fase de implantación.

Por su parte, Grégoire aprendió que las épicas deben completarse en menos de 28 días:

• 14 días en la fase de análisis: entre la creación de la épica y la creación de las historias de usuario.
• 7 días en la fase lista para desarrollarse: entre la creación de las historias de usuario y la primera línea de código.
• 7 días en la fase de desarrollo: entre la primera línea de código y el lanzamiento de la última historia de usuario de la épica.

Con base en esto, descubrimos que 8 épicas de un total de 10 estaban retrasadas:

• 8 tardaron más de 14 días en la fase de análisis.
• 3 tardaron más de 7 días en la fase lista para desarrollarse.
• 1 tardó más de 7 días en la fase de desarrollo.

El costo del inventario

Con una comprensión clara de los primeros pasos necesarios para acercarnos al plazo de entrega estándar, ahora podemos abordar la fase de análisis: el inventario de historias que el equipo tendrá que desarrollar. Profundizamos en el proyecto de Frédéric para ver la “edad” de las historias. El ochenta y ocho por ciento de ellas tenía más de 7 días de antigüedad.

Esta fase puede dividirse en tres etapas. Primero, al crearse, la historia de usuario se almacena en el backlog. En algún momento, el responsable del producto prioriza el backlog. Mueve lo que quiere que el equipo desarrolle a otra columna llamada "por especificar". Una vez por semana, el equipo especifica cómo codificar todos los tickets de esa columna. Al final, mueven la historia a la columna “especificada” antes de desarrollarla. Esta es la distribución:

• En el backlog: 65 de las 65 historias tenían más de 7 días.
• “Por especificar”: 14 de las 17 historias tenían más de 7 días.
• “Especificada”: 6 de un total de 14 tenían más de 7 días.

En el proyecto de Gregoire, este ejercicio fue aún más importante, ya que 11 épicas de un total de 11 se habían creado hacía más de 14 días.

Sabemos que el inventario tiene muchas consecuencias, aunque todavía no hayamos estimado su costo. Sin embargo, éramos conscientes de que el equipo repasaba cada elemento, semana tras semana, preguntándose si debían hacerlo de inmediato o más tarde. Por su parte, el responsable del producto dedicaba mucho tiempo a gestionar su backlog, teniendo que encontrar la mejor manera de priorizar historias y épicas. Además, nuestros clientes estaban perdiendo oportunidades de negocio. Los usuarios que esperan funcionalidades que les ayuden a mejorar su productividad se decepcionan al no verlas liberadas, y los clientes siguen sufriendo con funcionalidades para las que hay mejoras en el backlog y, así, ven caer sus ventas poco a poco.

Para reducir el lead time, nos dimos cuenta de que necesitábamos reducir el inventario de épicas e historias. El primer paso fue identificar las fuentes de las historias y cuántas historias generaban.

1. El 18,7% de las historias se crea a partir de la retroalimentación de los usuarios finales y de los problemas que enfrentan en la aplicación.
2. El 28% de las historias lo crea el equipo cuando encuentra algo que mejorar.
3. El 53,3% es inventario en proceso: lo que no logramos concluir en las semanas anteriores, las investigaciones que iniciamos y no pudimos concluir y las historias que el responsable del producto no priorizó.

Esto reveló todo el desperdicio que tenemos en nuestro proceso. La fase de análisis es nuestro inventario de historias y épicas. Durante toda la semana, el equipo sube y baja las historias y las épicas en el backlog para priorizarlas. Leen cada historia más de una vez para asegurarse de si es o no el momento adecuado para trabajar en ella - una especie de sobreprocesamiento. Y también sobreproducimos, agregando nuevas historias al backlog e identificando estrategias técnicas para ellas mientras están defectuosas.

SIN PULL Y CON EL FLUJO ROTO

Nos enfocamos en la sobreproducción y en los defectos. Hace años, definimos un inventario mínimo de historias que el responsable del producto debe crear para garantizar que el equipo siempre tenga algo que hacer, pero no un máximo. Pero descubrimos, entre otras cosas, que el responsable de un producto seguía creando historias aunque el backlog ya estuviera lleno. Aquí, el sistema pull parecía estar roto, con el responsable del producto empujando historias sin considerar la capacidad del equipo. Irónicamente, el responsable del producto se quejaba de que no tenía tiempo suficiente para trabajar en cosas importantes, como recibir retroalimentación de los usuarios, hacer experimentos con usuarios, etc. ¡Parece que encontramos una solución para su falta de tiempo!

Hay otra cosa interesante. No distinguimos entre diseñar la funcionalidad y dividir las épicas en historias de usuario. Esto ocurre al mismo tiempo, lo que genera mucha información ausente o incompleta. También hace que otros departamentos (diseñadores, traductores, marketing, equipo de infraestructura) descubran en el último momento que necesitan hacer algo crítico para la entrega de la funcionalidad. En esos casos, el flujo se interrumpe.

Ahí es donde estamos hoy. La ventana está un poco más limpia y, aunque creo que el futuro seguirá siendo desafiante, ahora somos conscientes de lo que nos estamos perdiendo. Más importante aún, ahora estamos enfrentando nuestros problemas, lo que significa que nuestro mañana solo puede ser más brillante y lleno de nuevos aprendizajes e innovaciones. Los mantendré informados sobre nuestro progreso dentro de algunos meses ...