Waterfall planifica todo primero y ejecuta después; Agile entrega en ciclos cortos y ajusta sobre la marcha. Hasta aquí el resumen de tarjeta. La decisión real —cuál usar en tu proyecto— merece algo más de detalle, porque equivocarse sale caro en las dos direcciones.
Cómo trabaja waterfall
El modelo en cascada ordena el proyecto en fases secuenciales: requisitos, diseño, construcción, pruebas, entrega. Cada fase termina y se valida antes de empezar la siguiente, con documentación formal en cada frontera.
Esta rigidez, que tan mala prensa tiene, es una virtud en el contexto adecuado. Cuando construyes un puente, quieres que el cálculo de estructuras esté cerrado y firmado antes de pedir el hormigón. La secuencialidad no es burocracia: es que el coste de volver atrás es enorme.
Cómo trabaja Agile
El enfoque ágil asume lo contrario: que no sabemos lo suficiente al principio y que intentar saberlo todo antes de empezar es una fantasía cara. Así que se trabaja en iteraciones de una a cuatro semanas, cada una con una entrega funcional.
El plan detallado solo existe para la iteración en curso. El resto del trabajo vive en un backlog priorizado que cambia según lo aprendido. El cliente no espera seis meses para ver algo: lo ve cada dos semanas y corrige el rumbo con hechos, no con suposiciones.
La comparación honesta
Previsibilidad. Waterfall gana: fecha, coste y alcance comprometidos desde el día uno. Es lo que un contrato con penalizaciones necesita. Agile ofrece previsibilidad por iteración, pero la fecha final de «todo el alcance» es, por diseño, una estimación viva.
Gestión del cambio. Agile gana sin discusión. Un cambio en waterfall a fase tardía obliga a rehacer documentos, replanificar y renegociar; en Agile es una línea que sube posiciones en el backlog.
Detección de errores de enfoque. Agile los descubre en la review de la segunda semana; waterfall puede arrastrarlos hasta las pruebas finales, cuando corregirlos cuesta multiplicado. Este punto, más que ningún otro, explica el auge ágil en software.
Exigencia al cliente. Waterfall le pide un esfuerzo grande al principio (definir requisitos) y otro al final (aceptar entregables). Agile le pide presencia constante: priorizar, asistir a demos, decidir. Un cliente que no puede dar esa dedicación rompe el modelo.
Dónde encaja cada uno
Waterfall: obra e instalaciones, proyectos regulados con documentación exigida por norma, alcances estables con contrato cerrado, integraciones con dependencias externas rígidas.
Agile: desarrollo de producto digital, proyectos donde el usuario final es una incógnita, contextos de innovación, equipos internos con acceso directo al negocio.
El falso dilema
La pregunta «¿waterfall o agile?» asume que hay que elegir religión. En la práctica, el patrón más común en empresas serias es híbrido: compromisos de hitos hacia el cliente con ejecución interna en sprints.
Funciona porque cada capa recibe lo que necesita: dirección y cliente obtienen fechas y presupuestos que pueden firmar; el equipo obtiene ciclos cortos con feedback real. La frontera entre ambos mundos —qué se promete fuera y cómo se absorbe dentro— es donde un buen director de proyecto se gana el sueldo.
Si dudas, mira la estabilidad de los requisitos y el coste del cambio, no la moda. Y desconfía por igual del comercial que vende «agile» como sinónimo de rápido y del gestor que exige plan cerrado para un producto que nadie ha usado todavía.