Metodología Waterfall vs Agile: cuándo elegir cascada

Antes de metodologías, roles y ceremonias, contesta esto con honestidad:

• Sí, con detalle y firmas: requisitos estables, regulaciones, contrato cerrado, diseño físico o fechas inamovibles → cascada (o híbrido muy cercano).
• No, lo vamos a aprender con usuarios o el mercado: producto digital, marketing, innovaciones → Agile (Scrum, Kanban u otro ritmo iterativo).

Esa es la misma lógica del pilar metodologías de gestión de proyectos: la metodología responde al tipo de incertidumbre, no a la moda de LinkedIn.

Waterfall planifica y acuerda el “qué” antes de construir en volumen. Avanza por fases secuenciales — típicas: requisitos → diseño → construcción → prueba → despliegue/cierre — con gates de aprobación. Cambiar de idea a mitad de camino es caro a propósito: el proceso asume que el costo de rehacer es mayor que el costo de analizar bien al inicio.

Encaja con las 5 fases de un proyecto cuando esas fases son realmente secuenciales y el alcance no debería moverse sin control de cambios formal.

Ejemplos honestos: obra o instalación con planos, migración con ventana de corte fija, cumplimiento normativo con checklist auditado, evento con fecha que no se mueve.

Agile no es “sin plan”: es planificar en ciclos cortos, entregar valor usable seguido y ajustar con lo aprendido. Scrum y Kanban son implementaciones; el manifiesto es la brújula (individuos e interacciones, software que funciona, colaboración con el cliente, respuesta al cambio).

Encaja cuando el alcance va a evolucionar y pretender congelarlo el día 1 es mentira contractual o autoengaño del equipo.

Entre Scrum y Kanban, la segunda pregunta es ritmo fijo vs flujo continuo — ver Scrum vs Kanban.

Híbridos honestos:

• Cascada en el contrato, iterativo en la ejecución interna: el cliente firma fases y entregables; el equipo entrega demos internas cada 2 semanas para no descubrir el desastre al final.
• Agile con milestones fijos de negocio: sprints cortos hacia una fecha de lanzamiento inamovible, con recorte de alcance (no de calidad).

Disfraces:

• “Hacemos Agile” pero el alcance está cerrado en un Gantt de 9 meses sin margen de aprendizaje.
• “Hacemos Waterfall” pero cambian requisitos cada semana sin control de cambios ni ajuste de fecha/presupuesto.
• Daily + tablero Kanban + cero entregas usables = teatro con stickers.

Señales de que solo renombraste el proceso:

• El “sprint” es un mes de tareas de un plan que no se puede tocar.
• No hay review con feedback que pueda cambiar el próximo ciclo.
• La retrospectiva no produce cambios de proceso (ver formatos de retrospectiva).
• El planning es un wishlist, no un compromiso de capacidad.

No hay vergüenza en usar cascada cuando corresponde. Hay desperdicio en fingir Agile para quedar bien en la industria y seguir planificando como en 2005 sin la disciplina de 2005.

1. Escribe en una frase el resultado del proyecto y cuánto puede cambiar el “qué”.
2. Marca en la tabla de arriba 3–5 señales dominantes.
3. Elige el sistema mínimo: fases y gates (cascada) o ciclos y feedback (Agile).
4. Define cómo se aprueban cambios de alcance — sin eso, cualquier metodología se pudre.
5. Revisa a las 2–4 semanas: ¿estamos aprendiendo o solo reportando? Ajusta el ritmo, no el eslogan.