Un cuento ágil de Navidad

 
Siempre que llegan estas fechas recuerdo las navidades del 2001. Éramos un equipo de veinte personas, y ese año no tuvimos vacaciones. Estábamos en medio de uno de los proyectos más grandes en los que he podido trabajar: era a nivel estatal, nuestro cliente era administración pública, y el producto a generar un software para gestión que, después de un año de trabajo, simplemente existía en forma de pequeños prototipos; eso sí, había muchísima documentación generada. Era imposible cerrar alcance, cada día descubríamos nuevos requisitos, cada día el final quedaba más lejos. En ese proyecto, el concepto de scope creep, lo aprendimos a golpes.
 

Sacrificar la Navidad

 
Ese diciembre, nuestro cliente (y con razón, mirándolo con la perspectiva de los años), nos puso un ultimátum: o en enero entregábamos un producto funcionando o cancelaba el proyecto. En ese momento, el equipo de trabajo nos conjuramos para conseguirlo. Entendíamos la necesidad, teníamos un conocimiento bastante claro de lo que se requería, teníamos también el conocimiento técnico… Pensábamos que lo que nos faltaba simplemente eran manos y creíamos que podríamos suplirlo con horas y esfuerzo máximo. Acordamos con el cliente lo que podríamos entregar y lo intentamos, a costa de no tener Navidad ese año. Recuerdo salir de trabajar corriendo para asistir a la cena de Nochebuena con la familia y volver al día siguiente temprano a la oficina. Y no fui el único… esos días aprendí mucho de lo que significaba compromiso de equipo.
 

 
Llegó enero, y a principios de ese mes, como regalo de Reyes, entregamos lo que pudimos: un software incompleto, poco probado, lento y que, directamente, al usuario no le servía.
 

Una segunda oportunidad

 
Se imponían cambios. Desconozco qué maniobras hubo a nivel comercial pero el caso es que nos dieron una nueva oportunidad. A mí en aquel momento, el problema me superaba, no sabía cómo podíamos enderezar la situación y, tampoco desde dentro del equipo veía ideas consistentes que no sirvieran sólo para ganar tiempo.
 
La ayuda llegó desde fuera: vino una persona externa que nos ayudó a ver las cosas de otra manera, poniendo el foco en lo importante, liberando los liderazgos internos que estaban latentes y que, a la que se sintieron escuchados, dieron con la solución: teníamos un equipo de analistas que conocían a la perfección los objetivos de negocio, un conjunto de developers y arquitectos que habían aprendido muchísimo acerca de la mejor solución técnica, sólo faltaba combinar ambos conocimientos, con la ayuda del cliente.
 
El resumen de cómo resolvimos la situación fue básicamente ese: poner a trabajar developers y analistas juntos, colaborando diariamente con cliente, y entregando software a los usuarios a través de iteraciones cortas para aprender juntos lo que se necesitaba, apostando por máxima calidad y no por máxima funcionalidad. Además, entendiendo la funcionalidad no como procesos de negocio, sino como la ayuda al usuario a hacer su trabajo.
 

 

El final del cuento

 
En febrero entregamos la primera versión. Mínima en funcionalidad, absolutamente fantástica en rendimiento, usabilidad y potencialidad. Después de un año y algo de trabajo entregamos al cliente menos de un 5% de los requisitos iniciales, pero ¿sabéis qué? estuvo encantado. Un año más tarde el software entró en funcionamiento en las oficinas. Ese mismo software estuvo operativo (en continua evolución) durante los diez siguientes. Y este fue el final feliz del cuento.
 
Ese mismo año en otra parte del mundo, unos cuantos gurús del software estaban reunidos, enfrentándose a los mismos problemas y proponiendo soluciones para ello. El resultado de su reflexión se llamó Manifiesto Ágil y fue el inicio de muchos de los cambios que hoy están viviendo las organizaciones. Con mucha humildad, puedo decir que nosotros llegamos a conclusiones parecidas que nos sirvieron para resolver el problema en nuestro proyecto. A veces, el problema está en que nos empeñamos en seguir una manera de trabajar que, como insistentemente nos dice la experiencia, no funciona para la construcción del software. Es puro sentido común.
 

 

¿Y qué aprendizajes me llevo de esa experiencia casi veinte años después?

• En primer lugar, la importancia de tener el foco claro en cliente, en valor y también en calidad (técnica) para el éxito de los proyectos.
• También la importancia de disponer de una ayuda externa, no para darnos la solución, sino para abrir la perspectiva mental, alejarnos de las inercias, y activar liderazgos ocultos. El éxito en los grandes cambios requiere de ayuda externa, eso sí, con liderazgo interno.
• El poder de la experimentación como base del descubrimiento y el aprendizaje.
• La importancia de disponer de un equipo comprometido. Es la base para todo lo demás.

 
 
Como reflexión personal, además, a partir de aquella situación entendí que el proceso de aprendizaje nunca acaba, que no hay una manera única y correcta de hacer las cosas, que la actitud de hacer challenge, desafiar, constantemente nuestra manera actual de trabajar es la base del aprendizaje y la mejora continua. Intento aplicármelo siempre desde entonces.
 
Por último, aprendí que las navidades están para celebrarlas en paz y en familia, con las personas que quieres. Eso es lo más importante.
 

¡¡Felices fiestas!!