El año que viene se cumplirán 25 años del Manifiesto Ágil y del arranque de la “moda de la agilidad”.
(¡Un cuarto de siglo ya! Y parece que fue ayer cuando nos aprendimos los principios con lágrimas en los ojos y post-its en la mano…).
Si no tienes ni idea de qué va esto del Manifiesto Ágil, tranqui, que no te voy a dar la turra. Puedes mirar este artículo para situarte, y luego vuelves, que aquí te espero con café ☕.
La cosa es que a principios de este siglo (¡qué viejuno suena eso! 😅), el panorama de la gestión de proyectos era más rígido que un lunes sin café: el modelo en cascada reinaba, y con él solo había una certeza... no funcionaba demasiado bien. Así que apareció la Agilidad, cual héroe inesperado en peli de Marvel, con una promesa: “¡otra forma de hacer las cosas es posible!”.
Muchos nos tiramos a sus brazos con entusiasmo. Claro que por el camino hubo confusión, postureo, e interpretaciones más creativas que una reunión de naming. Y así, con el tiempo, surgió el típico rumor de “la agilidad no funciona” o el famosísimo “Agile is Dead”.
Pero nada más lejos de la realidad.
(Respira hondo, está viva. Quizá algo despeinada, pero vivita y coleando).
Eso sí: la agilidad no es mágica. No es un botecito de unicornio líquido que se le echa a un proyecto y ¡pum! todo fluye. Tampoco significa que las metodologías tradicionales sean el demonio. Cada cosa tiene su momento.
La Agilidad es una mentalidad, no una receta de cocina. Parte de la idea de que el cambio no es la excepción, sino el pan de cada día en el mundo empresarial. Así que, en vez de pelearte con él, mejor te haces amigo suyo, lo abrazas con ciclos cortos, valor entregado cuanto antes y mucha inspección.
También promueve un enfoque de personas basado en autogestión y trabajo en equipo, ideal si no quieres acabar en un grupo de WhatsApp con 17 jefes y cero decisiones.
En cambio, los modelos más tradicionales, conocidos como “cascada” o Waterfall, están enfocados a un modelo secuencial basado en la predicción. En estos modelos se enfocan en planificar como si todo fuera a salir según lo previsto: defines, analizas, planificas, ejecutas, validas, corriges... y repites si te queda presupuesto.
Eso sí: si algo cambia (y siempre cambia), toca replanificar, justificar, sudar... y cruzar los dedos… 🤞
🥋 ¿Ágil es el bueno y Cascada el malo?
¡No! No estamos en una peli del oeste 🤠. No hay buenos ni malos, solo contextos diferentes.
Es decir, que como todo en la vida, no es un blanco o negro, un bien y un mal. Hay muchos matices. Y dentro de esos matices hoy os vengo a explicar cómo intento decidir cual es la metodología a utilizar en un proyecto concreto. O en un servicio. O en un producto.
Y es que en muchos casos, lo que de verdad funciona es una solución híbrida, de esas que no caben en un post-it pero sí en la vida real.
Para decidir qué modelo usar en un proyecto (o un servicio, o un producto, o lo que toque), me fijo en siete factores clave. Te los dejo aquí con explicación y un par de guiños:
📊 Los 7 Magníficos (factores, no vaqueros)
1. 🔧 ¿La solución técnica es un misterio?
Sí → ¡Agilidad al rescate! Ideal para explorar, probar, equivocarse barato y aprender rápido.
No → Si ya se ha hecho mil veces y todo está bajo control, un enfoque tradicional puede ser más ágil que la agilidad mal entendida.
2. 🎯 ¿Los requisitos cambian más que los precios del súper?
Sí → Agile brilla aquí. Está diseñado para el cambio, no para sufrirlo.
No → Si está todo clarinete desde el inicio, y no hay margen para giros de guion, la cascada puede ser tu aliada.
3. 💥 ¿Es un sistema crítico de esos que no pueden fallar?
Sí → Ojito. No es buena idea aplicar agile a proyectos donde un fallo puede costar vidas o millones. No estás haciendo una app para hacer memes.
No → Si puedes equivocarte sin que salte la alarma nuclear, adelante con los sprints.
4. 🧠 ¿El equipo tiene experiencia y madurez?
Sí → Maravilloso. Agile necesita gente con tablas, que sepa autogestionarse sin que parezca una clase de educación física sin profe.
No → Si hay mucho perfil junior, quizá es mejor tener un marco más estructurado y con más andamios para que no se caiga todo a la primera de cambio.
5. ⏳ ¿El cliente tiene tiempo para implicarse?
Sí → Perfecto. Agile requiere presencia, feedback, disponibilidad. No vale con aparecer el primer día y el último con una lista de quejas.
No → En ese caso, mejor usar una metodología que no dependa tanto del contacto constante. O pídele al cliente que se clone.
6. 🌍 ¿El equipo está juntito o cada uno en una punta del planeta?
Juntito → ¡Ideal para Agile! La comunicación fluye, la química surge, y los cafés se comparten.
Distribuido → No es imposible, pero hay que currárselo el doble en coordinación, sincronización y en evitar que alguien hable solo en las dailys.
7. 💸 ¿El contrato es de precio fijo y alcance cerrado?
Sí → Malas noticias: eso y la agilidad no se llevan bien. Si el proyecto está cerrado como una lata de sardinas, toca cascada.
No → Entonces puedes proponer marcos más flexibles, contratos basados en entregas por valor, o incluso presupuestos por iteraciones.
(Por cierto, si te preguntas cómo montar propuestas comerciales más ágiles, échale un ojo a la presentación de Antonio Lorente en la CAS 2024, que el tío lo explica de maravilla).
8. ❤️ ¿Y la relación con el proveedor?
Fundamental. Para usar Agile, necesitas una relación de confianza y largo plazo. Si el proveedor es nuevo, y está pensando más en cobrar que en colaborar, es difícil que salga algo fluido.
✅ En resumen…
No se trata de ser “pro-Agile” o “anti-cascada”. Se trata de usar la cabeza y el contexto.
Puedes tener un enfoque ágil con más o menos Scrum, más o menos sprints, o incluso mezclando cosas. Como decía mi abuela: “no es lo que usas, es cómo lo usas” (vale, mi abuela no decía eso, pero encajaba aquí).
¿Y tú? ¿Cómo decides qué enfoque utilizar en tus proyectos?
📅Efeméride de la semana
Ayer 10 de abril fue el Día de la Ciencia y la Tecnología. Y como Tecnología es uno de los palabros del título de esta newsletter, pues no está de más recordarlo, a modo de santoral 😝