La trágica consecuencia
El otro día volvió a pasar. Un compañero del equipo de desarrollo anunció que se marchaba de la empresa; que «su lucha había terminado» -la misma frase que se dicen los terrestres de la serie Los 100 cuando alguien va a morir-.
Un sentimiento amargo me recorrió por dentro como si fuera un calambre, de arriba a abajo. Me alegré muchísimo por él, claro que sí, porque según él «se va a un lugar mejor» pero no pude evitar pensar «¿por qué ha tenido que pasar esto?«. Se supone que los equipos ágiles son estables. Pocas personas, pero siempre las mismas, para que el trabajo diario sea cada vez más bueno, que evolucionemos. Qué lástima. Sobre todo cuando el compañero lo vale de verdad y sabes que los motivos por los que se va son porque siente que no hay margen de mejora en la empresa: «hemos tocado techo«.
Falta de visión global
Cuando he preguntado a ciertos compañeros por qué sienten que ya no tienen más herramientas para seguir, me dicen que «con el enfoque a corto plazo con el que año tras año trabajamos es imposible mejorar, no tenemos tiempo«. Y parece curioso, pero es justo lo que se le pide a los equipos de desarrollo que hagan: que mejoren.
Los managers nos piden a los scrum master que nos esforcemos por aumentar la eficiencia, resolver impedimentos, señalar el desperdicio… pero de forma localizada dentro del equipo de desarrollo. Mejor si no nos salimos de ese círculo porque entonces todo se complica: no podemos cambiar nada y realmente no estamos haciendo autocrítica. Con suerte podemos trabajar un poco en el área del product owner también (si te toca uno que no sigue siendo un manager en espíritu y acepta colaborar).
Me parece curioso cómo todo acaba simplificándose únicamente al equipo scrum, a aumentar la velocidad principalmente dentro del equipo, poniendo en vereda a los desarrolladores ya que se dispersan del foco y mejoran el código porque les apetece, en lugar de hacer lo que tienen que hacer: acabar las tareas. Y yo me pregunto: ¿de verdad alguien cree que un desarrollador refactoriza legacy por gusto? Refactorizar código cuesta mucho. Por gusto estaría haciéndose una app propia o viciándose a un juego de estrategia. Los desarrolladores que prefieren programar con calidad, con tests automáticos e intentando dejar el código más mantenible para sus «yo» del futuro y los de sus compañeros son los que están aumentando la velocidad de verdad. Pero ¡ouch! no aumentan la velocidad de hoy ni de mañana ni de este sprint, aumentan la velocidad a medio-largo plazo.
¿Por qué nos pasa esto?
Y en este punto es donde me paro. Tenemos managers que seguramente sienten presión por la facturación, y por ello creo que nos piden lo que piden: «¿has aumentado la velocidad en este sprint? ¿no? ¿y por qué esta tarea tiene 100 horas imputadas cuando en la estimación ponía 20 horas?«. En descuidarte la persona que estimó ni siquiera era desarrollador y encima, fuera quien fuera, seguramente estimó deprisa y corriendo por presión.
A lo mejor es que este modelo de proyectos en cascada debe cambiar porque no es sostenible, aunque «haya sido siempre así». A lo mejor tenemos que entregar más rápido y con menos errores a nuestros clientes habituales porque están hartos de ver que su software (entregado cada 2 años) tiene demasiados bugs. ¿Y si entregáramos más a menudo al cliente e integráramos su feedback mucho antes? En pequeños ciclos podríamos calcular mejor el valor aportado y no haría falta inspeccionar tan al detalle cuánto tardamos en subtareas.
Dosis de systems thinking
La visión del sistema completo es necesaria. Tratar la velocidad o eficiencia con un enfoque simplista y cortoplacista nos duele a todos: a desarrolladores, a scrum masters, a product owners, a stakeholders y a managers. Creo de verdad que si dejamos de «micro-medir» y nos enfocamos en «macro-medir» iremos por el buen camino. Midamos tendencias acumuladas a lo largo del tiempo, midamos valor entregado a cliente de verdad y no abusemos del micromanaging de los equipos simplemente porque es fácil:
Quizás forzar a obtener una acción en el corto plazo no sea lo más adecuado en todos los casos. Quizás haya retrospectivas de equipos scrum donde no salga ninguna acción/experimento viable a aplicar en el siguiente sprint, quizás no haya nada que se pueda hacer al día siguiente de que el compañero se vaya de la empresa, quizás no haya soluciones simplistas o cortoplacistas para todos los problemas. Por ello, aprender de verdad para el futuro a medio-largo plazo a lo mejor es lo más sostenible.