Por qué cambié de opinión sobre las metodologías ágiles puristas
Hola a todos, soy Roberto Hernando, desarrollador web con unos cuantos años ya a mis espaldas. Hoy quiero hablaros de un tema que me ha dado muchas vueltas la cabeza y sobre el que he cambiado bastante de opinión: las metodologías ágiles. Sí, esas de las que todos hablamos y que, a veces, parecen la panacea para cualquier proyecto. Os voy a contar mi experiencia, desde mi fervor inicial hasta mi actual postura, mucho más flexible y pragmática. A ver si os sentís identificados, o al menos, os sirve para reflexionar un poco.
Mi época de 'Agile Evangelist'
Cuando empecé a trabajar con metodologías ágiles, concretamente con Scrum, me convertí en un verdadero fanático. Creía a pies juntillas en todo: sprints de dos semanas, daily meetings, retrospectivas, planning poker... ¡Todo! Pensaba que era la solución a todos los problemas de desarrollo, que con esto se acababan los proyectos eternos y los entregables que no se parecían en nada a lo que el cliente quería. Recuerdo que en mi anterior empresa intenté (casi obligué) a todo el mundo a adoptar Scrum. Tenía la sensación de que quien no lo hacía, estaba remando en dirección contraria. Me sentía como un evangelizador, predicando la palabra de la agilidad a los cuatro vientos.
Claro, al principio todo parecía ir bien. Teníamos sprints más cortos, el cliente veía avances más rápido, y parecía que estábamos más organizados. Pero poco a poco empezaron a surgir problemas. Las daily meetings se convirtieron en un tostón de quince minutos donde cada uno soltaba su rollo sin escuchar a los demás. El planning poker, en una discusión interminable sobre si una tarea era de 3 o de 5 puntos (¡como si eso importara tanto!). Las retrospectivas, en sesiones de quejas y reproches sin llegar a soluciones concretas. Y lo peor de todo: la sensación de que estábamos siguiendo un proceso por seguirlo, sin entender realmente por qué lo hacíamos.
El choque con la realidad: La rigidez mata la creatividad
El problema, creo yo, era que estaba intentando aplicar Scrum al pie de la letra, sin adaptarlo a las necesidades del proyecto o del equipo. Era como intentar meter un cuadrado en un círculo. Me había obsesionado tanto con la metodología que me había olvidado de lo más importante: las personas y el objetivo del proyecto. Empezamos a perder la flexibilidad, la capacidad de adaptación real que se supone que proporciona Agile. La rigidez del proceso nos estaba ahogando la creatividad y la capacidad de innovar.
Además, me di cuenta de que no todos los proyectos encajan bien con Scrum. Hay proyectos más pequeños, con un equipo reducido, donde quizás es más eficiente utilizar un enfoque más ligero, como Kanban. Y hay proyectos donde, simplemente, el cliente no está dispuesto a participar activamente en el proceso, lo que dificulta mucho aplicar Scrum de forma efectiva.
¿Por qué me parece importante la agilidad, aunque no sea purista?
A ver, que no me malinterpretéis. No estoy diciendo que las metodologías ágiles no sirvan para nada. Al contrario, creo que son muy valiosas si se aplican correctamente. Lo que quiero decir es que no debemos ser dogmáticos. No podemos pensar que una metodología es la solución mágica a todos los problemas. Tenemos que adaptarla a nuestras necesidades, a nuestro contexto, y a nuestra cultura. La agilidad, para mí, se trata de tener la capacidad de adaptarnos rápidamente a los cambios, de colaborar estrechamente con el cliente, y de entregar valor de forma continua. Y eso se puede conseguir de muchas maneras diferentes.
Lo que he aprendido: El punto medio es la clave
Después de varios años y muchos proyectos, he llegado a la conclusión de que lo mejor es encontrar un punto medio. Un enfoque híbrido que combine lo mejor de las metodologías ágiles con un poco de sentido común. Por ejemplo, sigo utilizando sprints, pero no siempre de dos semanas. A veces los hago de una semana, a veces de tres, dependiendo de la complejidad de las tareas. También sigo haciendo daily meetings, pero las he reducido a cinco minutos y las he enfocado en resolver problemas concretos, no en un simple informe de lo que he hecho. Y las retrospectivas las hago cuando realmente siento que son necesarias, no obligatoriamente al final de cada sprint. Además, ya no me obsesiono tanto con la documentación. Prefiero tener un código bien comentado y unas pruebas automatizadas sólidas que un montón de documentos que nadie va a leer.
Otro aspecto importante que he aprendido es la importancia de la comunicación. No solo con el cliente, sino también dentro del equipo. Cuanto más transparente y abierta sea la comunicación, más fácil será resolver los problemas y adaptarse a los cambios. Y por supuesto, la confianza. Confiar en el equipo, darles autonomía y responsabilidad. Al final, son ellos los que van a construir el producto, no yo.
Reflexiones finales
En resumen, mi viaje con las metodologías ágiles ha sido un camino de aprendizaje constante. Empecé siendo un 'Agile Evangelist', convencido de que tenía la verdad absoluta. Luego, me di cuenta de que la realidad era mucho más compleja y que la rigidez mata la creatividad. Ahora, intento aplicar la agilidad de forma pragmática, adaptándola a cada proyecto y a cada equipo. Y creo que he encontrado un punto medio que me funciona bastante bien. Espero que mi experiencia os sirva para reflexionar sobre vuestra propia forma de trabajar y para encontrar vuestro propio camino hacia la agilidad. Al final, de eso se trata, ¿no? De aprender y mejorar constantemente.
Ahora, contadme vosotros. ¿Cómo ha sido vuestra experiencia con las metodologías ágiles? ¿Sois puristas o preferís un enfoque más flexible? ¡Me encantaría leer vuestros comentarios!