Holgura, El Secreto para una Gestión Efectiva del Tiempo y los Recursos
Cómo la planificación flexible puede llevar a tu equipo al éxito
Estás sentado en medio de esa sala con tu equipo, mirando una pizarra. La nube de post-its que se extiende de izquierda a derecha puede no significar nada para cualquiera que camine por el pasillo. Sin embargo, tú y tu equipo no veis esos cuadraditos de colores, sino un puñado de ideas que necesitan ser validadas lo antes posible.
Sales de la sala con un objetivo claro: tenemos nuestro primer incremento, hagámoslo realidad. Este proceso u otro parecido se repetirá una y otra vez, iréis pivotando, aprendiendo y el producto empezará a tomar forma con la ayuda de vuestros clientes.
Paulatinamente, las cosas empiezan a ponerse lentas. El equipo no se siente productivo, implementar una nueva historia se parece cada vez más a caminar por aguas pantanosas. Para dar un paso hay que tirar de la pierna con los dos brazos, cuesta avanzar. Has seguido todas las prácticas que prometían mantener el coste del cambio controlado y, sin embargo, no lo parece. ¿Qué ha pasado?
Eduardo Ferro (conocido como @eferro) acuñó el término 'coste basal del software' para explicar por qué añadir nuevos comportamientos a nuestro producto es cada vez más costoso. XP recorre la misma senda, pero asume que con las prácticas correctas podremos mantener el coste del cambio bajo control. Kent Beck, en su boletín de noticias, 'admite' que la virtud está en el punto medio y que el coste del cambio no se mantiene estable a lo largo del tiempo, aunque uses XP, por tanto, debemos tomar un enfoque más empírico. Nosotros en el podcast hemos hablado en repetidas ocasiones sobre la entropía y cómo el código tiende al caos sin los cuidados necesarios.
Si llevas suficiente tiempo en esto, alguna vez habrás tenido que correr para llegar a una fecha límite. Si has mirado atrás después, seguro que has encontrado un reguero de despropósitos a tu paso que se parece un poco a lo que describimos en la historia inicial. Estas experiencias me hacen pensar que aunque hay múltiples factores que intervienen en el coste del cambio, la mayor parte de ellos están influenciados por una presión excesiva en la entrega.
El lead time y el throughput son cosas distintas. 'Accelerate' llegó a la conclusión de que los equipos con un alto desempeño tienen un lead time corto, pero no dice nada del throughput. Entregar más no es lo mismo que entregar rápido. Nosotros queremos ambas cosas, pero incentivar demasiado la entrega perjudica la latencia del sistema. Necesitamos enfocarnos en el lead time, crear las condiciones para tener una entrega sostenible. Después ajustaremos el sistema para equilibrar la oferta con la demanda.
Nadie quiere llegar tarde a una cita. Pero es difícil estimar el trabajo con alta incertidumbre y múltiples dependencias que no controlamos. Si generamos holgura, podemos absorber esta variabilidad. Le daremos al equipo una nueva herramienta que seguro usará para reducir el coste del cambio, y finalmente llegaremos a nuestra cita.
Es un concepto simple de explicar pero complejo de aplicar. Para generar holgura, debemos planificar menos trabajo del que la capacidad del sistema permite. La mera proposición ya suele causar controversia. ¿Qué hará el equipo con ese tiempo extra? ¿No acabará el trabajo consumiendo todo el tiempo disponible? En mi opinión, un sistema al 100% de su utilización no puede mejorar. Por tanto, la generación de slack es una herramienta imprescindible en el contexto de la mejora continua.
No me enrollo más, te dejo con dos referencias que te lo explican mejor que yo:
'Stop Starting, Start Finishing!' es un cómic que se lee en un rato y que vale su peso en oro.
'Kanban: Successful Evolutionary Change for Your Technology Business', otro libro que, a pesar de ser antiguo, no ha perdido valor y que fue mi introducción a todo este mundo.