En mi trabajo como Coach Ágil – o Consultor, o Evangelista, o Agente del Cambio, o el “Tío de la Vara” Ágil, como prefieran ustedes llamarlo – una de las prácticas que suelo implementar con frecuencia y devoción es la celebración de laboratorios periódicos. Por poner un ejemplo, se trataría de dedicar cuatro horas cada dos semanas a investigación, desarrollo, aprendizaje, innovación y mejora continua. Esas cuatro horas pueden parecer mucho, pero apenas son el 5% del tiempo de un equipo de desarrollo. ¿Cuánto menos del 5% quiere invertir una empresa tecnológica, basada en la gestión del conocimiento de sus trabajadores, en aprender, mejorar, investigar e innovar?
Conozco al dedillo los intentos de esquivar esta inversión. “No, si a mi me parece bien que lean, aprendan e investiguen, pero… A ratos… No cuatro horas seguidas”. No tiene sentido. Si se van a invertir esas cuatro horas, lo mejor es que se celebren en un periodo de tiempo estructurado y sin interrupciones. Cinco minutitos allí y allá no dan para aprender idiomas, no se si me explico.
Otra clásica es la de “con lo retrasado que va el proyecto ahora“. Supongamos un proyecto de seis meses, iteraciones de dos semanas, medio día de laboratorio cada iteración… Total, seis días invertidos en laboratorios. ¿Me estás diciendo que el retraso típico de un proyecto de seis meses es una semanita de nada? ¿En serio? ¿Que esos seis días de laboratorio son la diferencia entre entregar a tiempo o no?
‘Amos anda…
Lo que pasa es que la “generación tapón” y sus discípulos aventajados consideran que cada minuto que no estamos aporreando teclas en silencio es un minuto “no productivo” – aunque luego se deshagan en ostentaciones sobre lo Ágiles que son o cómo en su empresa tienen “equipos”. En fin, otro día recordadme que deshaga de una vez por todas el paradigma mitológico de la productividad, que hoy estoy a otro tema.
Lo que me alucina es que cada vez que propongo la idea de los laboratorios la gente me pregunta qué hacer en ellos, cómo organizarlos. Mi pregunta sería “qué NO hacer”… Pero para dar una idea general he aquí una lista que incluí en mi primer libro:
- Diseño de nuevos productos, pruebas de concepto o prototipos
- Implementar nuevas herramientas o marcos de trabajo para programación, automatización de pruebas, integración y despliegue continuos, obtención de métricas de calidad del software, gestión de proyectos, colaboración del equipo…
- Aprender nuevos marcos de trabajo, lenguajes de programación o entornos
- Programación por parejas orientada a compartir conocimiento – las personas que administran un silo de conocimiento se emparejan con otras para que vayan aprendiendo sobre ello.
- Aprender o mejorar técnicas de desarrollo Ágil o de “Artesanía del Software” – por ejemplo, desarrollo orientado a tests, refactorización, aplicación de patrones de diseño o de arquitectura…
- Coding dojos, katas, hackathons, FedEx days, ping-pong programming y otras formas de mejorar el estilo de programación
- Desarrollar y reforzar un estándar común de desarrollo
- Leer libros técnicos y compartir los conocimientos adquiridos con el resto del equipo
- Dedicar tiempo de laboratorio a eliminar impedimentos detectados en la retrospectiva (técnicos o no)
- Trabajar en código heredado, ese que nunca tenemos tiempo de refactorizar para hacerlo más flexible, modular, eficiente, documentado y fiable.
- Hacer revisiones de código, es decir, revisar entre todos el código que cada uno ha hecho durante la semana para sugerir mejoras o aprender de él.
- Desarrollar y mantener una base de conocimiento. Puede ser un blog, un wiki, una guía de mejores prácticas, la documentación técnica del sistema…
En general mi consejo es que el tiempo de laboratorio no se relacione con el trabajo del día a día, sino que sea parte del esfuerzo general en mejorar al equipo, el producto, los procesos y el entorno. Ocasionalmente, el tiempo de laboratorio puede servir para investigar alternativas y opciones sobre los proyectos en los que estamos trabajando o incluso para cosas como pulir el entendimiento de los requisitos pero, de nuevo, mi consejo es que el tiempo de laboratorio se blinde de alguna manera contra las urgencias del día a día, ya que en caso contrario los proyectos y las prisas acabarán canalizando el tiempo de laboratorio.
Por último, es importante que cuando se hagan laboratorios se compartan los resultados del mismo. Una forma es realizar pósters o paneles donde se recojan los principales logros o aprendizajes obtenidos, ya que si no nunca faltará quien califique los laboratorios de “pérdida de tiempo”.
