Cómo segmentar el trabajo ayudó a un desarrollador a ver los problemas

Michael Ballé nos visitó recientemente en Theodo. Después de su recorrido por el gemba, nos dijo sin rodeos que no estábamos aplicando adecuadamente el sistema pull, porque no entendíamos su propósito.

Al verlo sorprendido, intentamos explicarle por qué creíamos que realmente estábamos jalando. "Tenemos sprints que solo duran una semana, y nuestras historias de usuario duran menos de un día", dijo Benoît, nuestro cofundador (un sprint es un período de tiempo durante el cual producimos funcionalidades para el software de los clientes, organizadas en historias de usuario). En nuestra industria, los sprints suelen durar entre dos semanas y un mes, y las historias de usuario, entre uno y cinco días. Así que pensábamos que lo estábamos haciendo muy bien.

"¡Por favor! En la manufactura, si un operador tarda más de 10 minutos en hacer algo, significa que no domina el contenido del trabajo", respondió Michael. Poco después, Benoît, nuestro coach lean Régis Medina y yo empezamos a pensar en formas de dividir el trabajo de nuestros desarrolladores en tareas más pequeñas de 10 minutos de duración.

DIVIDA EL TRABAJO, VEA LOS PROBLEMAS

Elegí experimentar con uno de los líderes técnicos del equipo, Nicolas Boutin. En ese momento, Nicolas lideraba un equipo de dos desarrolladores que habían fallado cinco sprints en las 10 semanas anteriores.

Pasé dos horas con él mientras construía una historia de usuario. Antes de empezar a programar, le pedí que enumerara y definiera cada etapa (de 10 minutos como máximo) que tendría que ejecutar para construir la historia. Luego calculó el tiempo de cada etapa. Aunque no supiera hacer algo, pensara que no sería capaz de terminar la etapa o se le acabara el tiempo, le dije que podía pedirme ayuda siempre que lo necesitara - tal como haría un operador en una planta de ensamblaje de Toyota al jalar la cuerda del andon.

Nicolas estaba trabajando en un formulario de registro para contratar una póliza de seguro de vida en línea, en el que el cliente indica la cantidad mínima de dinero que desea aportar. Nicolas dividió la historia de usuario en ocho etapas, con un total de 22 minutos y 10 segundos (en lugar de las aproximadamente cuatro horas que el equipo había estimado inicialmente):

1. Llenar los formularios en línea para llegar a la etapa 4 y ver la página donde el resultado final sería visible - 3 minutos.
2. Encontrar un código similar para copiar y pegar - 30 segundos.
3. Encontrar el lugar donde pegar el código copiado, pegarlo y adaptarlo con datos de muestra - 10 segundos.
4. Escribir un caso de prueba automático - 10 minutos.
5. Sustituir los datos de muestra por datos reales obtenidos de la base de datos según la póliza contratada - 1 minuto.
6. Probar en el navegador - 30 segundos.
7. Publicar el código en la plataforma de validación - 2 minutos.
8. Probar en la plataforma de validación - 5 minutos.

Si no encontraba ningún problema, Nicolas podría entregar la historia 10 veces más rápido de lo previsto anteriormente.

Observé, cronómetro en mano, cuando empezó a programar, y anoté todo lo que hacía. El primer problema surgió en la segunda etapa: a Nicolas le costó encontrar las tres líneas de código que necesitaba en el archivo de más de 300 líneas. El archivo era obviamente demasiado largo, y tardó dos minutos en encontrar el código correcto.

Después de pegar las líneas en el archivo correcto, la página dejó de funcionar. El diseño no era el esperado, con algunos bloques de contenido desalineados o ausentes. Nos dimos cuenta de que no había copiado todas las líneas que necesitaba. Dos horas después, Nicolas había completado seis de las ocho etapas que había enumerado. Tres etapas se realizaron en el tiempo estimado, y dos faltaban en el flujo. Jaló el andon cuatro veces. Al final, tardó poco menos de cuatro horas en completar la historia de usuario, tal como el equipo había estimado (por lo tanto, el largo proceso no tuvo impacto en el plan de producción).

Nos tomamos un tiempo para analizar los problemas que Nicolas encontró en cada etapa. Entre ellos: falta de conocimiento de la tecnología y de las herramientas que utilizaba; dificultad para leer el código y falta de adherencia a las convenciones internas de programación; y el hecho de que su IDE (Integrated Development Environment - básicamente el editor de código) no estaba configurado.

Siempre que fue posible, abordamos la causa raíz del problema para solucionarlo de inmediato. Para todos los problemas que no pudieron resolverse de inmediato, Nicolas añadió una tarea a su lista. Al final del día, estaba entusiasmado. "Hoy es el día en que más he aprendido desde que empecé a trabajar en Theodo", me dijo.

SOLUCIONE PEQUEÑOS PROBLEMAS PARA FORMAR LÍDERES

El experimento tuvo tanto éxito que decidimos extenderlo a todo el equipo que lidera Nicolas. Los resultados fueron excelentes: durante ocho semanas seguidas, cada sprint se entregó a tiempo. A lo largo de las últimas cuatro semanas, incluso mejoraron su productividad en un 40%. Además, a medida que resolvíamos los problemas, logramos crear un espíritu de kaizen en el equipo y descubrimos que teníamos cada vez más oportunidades de desarrollo del liderazgo.

Hoy, cada desarrollador aborda uno de los problemas más importantes que encuentra todos los días. Antes, los problemas no estaban claramente definidos - "Llevamos medio día de retraso" - lo que significaba que encontrar las causas de origen era como buscar una aguja en un pajar. Ahora investigan los problemas menos de 10 minutos después de que ocurren, para poder corregirlos de inmediato.

Por último, creemos que el papel de Nicolas en el equipo es mucho más claro. Como líder de equipo, ayuda a cada desarrollador a crecer y a tener éxito en su trabajo. La retroalimentación del equipo fue tan positiva que decidimos extender esta iniciativa a otros equipos. ¿Quizás una gran oportunidad para otro artículo?