Gestión de proyectos híbrida: cómo combinar Agile y Waterfall

Por Tara Minh · Actualizado el 10 de octubre de 2026

La gestión de proyectos híbrida combina las prácticas planificadas de Waterfall con la entrega iterativa de Agile dentro de un mismo proyecto. Por lo general, los equipos fijan de antemano los límites del alcance, el presupuesto y los puntos de control de cumplimiento, y luego construyen en ciclos cortos y ajustan los detalles a medida que aprenden.

Datos Clave

• La etiqueta "water-Scrum-fall" proviene de un informe de Forrester de julio de 2011 del analista Dave West, que la usó para describir cómo practican Agile en realidad muchas organizaciones (Forrester).
• El Pulse of the Profession 2024 de PMI (su 15.ª edición) reporta que el uso de enfoques híbridos creció del 20% en 2020 al 31% en 2023 (resumen de MPUG).
• La advertencia central de Forrester: el modelo no es malo de manera automática, pero es poco probable que los equipos que no deciden deliberadamente dónde caen los límites obtengan los beneficios de Agile (Forrester).
• Lo híbrido funciona mejor cuando puede indicar, para cada fase, si se planifica de antemano o se descubre sobre la marcha.

¿Qué es la gestión de proyectos híbrida?

La gestión de proyectos híbrida es una forma de dirigir un proyecto que usa deliberadamente métodos predictivos (al estilo Waterfall) para las partes del trabajo que son estables y métodos Agile para las que no lo son. No es un compromiso en el que todos hacen un poco de todo. Es una decisión, tomada por fase o por flujo de trabajo, sobre dónde existe certeza y dónde no.

La séptima edición de la Guía del PMBOK de PMI aplica sus principios sin importar el enfoque de entrega, predictivo, ágil o híbrido, y coloca la adaptación (tailoring) en el centro (vea nuestra descripción general de la Guía del PMBOK). En la práctica, eso significa que no elige primero un nombre de marca. Observa el trabajo y luego elige el enfoque que se ajusta.

Un ejemplo típico: una empresa que construye un nuevo portal de clientes tiene una fecha de lanzamiento fija, un presupuesto firmado y una revisión de seguridad que no puede omitir. Pero nadie sabe qué funcionalidades usarán realmente los clientes. Entonces la dirección aprueba el alcance y el presupuesto de antemano (predictivo), el equipo construye el portal en sprints de dos semanas (Agile), y la revisión de seguridad y la puesta en producción siguen una lista de verificación formal (predictivo de nuevo).

Si quiere ver primero las versiones puras, comience con Agile vs Waterfall, la metodología Waterfall y qué es la metodología Agile.

De dónde viene la idea: water-scrum-fall

Dave West, de Forrester, puso nombre a este patrón en 2011. Su informe, "Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today", sostenía que la adopción real de Agile se había alejado de las ideas del Manifiesto Ágil. Los equipos ejecutaban Scrum a mitad del proyecto, mientras que la recopilación de requisitos al inicio y la gestión de lanzamientos al final seguían siendo tradicionales (Forrester).

El nombre se quedó porque es preciso. Water es la planificación y los requisitos iniciales. Scrum es la construcción iterativa. Fall es la prueba formal, la aprobación y el lanzamiento.

West no lo calificó de fracaso. Su punto era que el modelo requiere una gestión deliberada de las dos fronteras: de water a Scrum, y de Scrum a fall. Si el feedback de cada sprint no puede cambiar los requisitos fijados en la fase water, los sprints solo entregan el plan original en piezas más pequeñas. Y si el resultado del sprint espera en una cola hasta un lanzamiento trimestral, la velocidad ganada en el medio se pierde al final.

Esa sigue siendo la mejor prueba de un híbrido sano hoy. Pregunte qué ocurre en cada frontera.

Modelos híbridos comunes

No existe un único híbrido. Estos son los patrones que verá con más frecuencia.

Lo híbrido frente a otros enfoques

Así se compara lo híbrido con los frameworks puros y con nombre propio, para que vea dónde hace cada uno sus concesiones.

Disciplined Agile merece una mirada si quiere un toolkit estructurado para elegir entre ciclos de vida en lugar de inventar su propia mezcla.

Cuándo lo híbrido es la decisión correcta

Use un enfoque híbrido cuando el proyecto tenga elementos fijos y fluidos, y forzarlo a un solo método dañaría el lado fijo o el fluido.

• Cumplimiento con incertidumbre. Un banco debe aprobar una auditoría en una fecha fija, pero las pantallas orientadas al cliente evolucionarán. Fije el rastro de auditoría y los pasos de aprobación. Itere sobre las pantallas.
• Hardware más software. Un fabricante de dispositivos no puede iterar semanalmente sobre moldes de inyección, pero la app complementaria puede publicarse en cada sprint.
• Programas grandes con ciclo de financiamiento. Finanzas aprueba un presupuesto anual; los equipos de entrega aún necesitan repriorizar cada mes.
• Equipos que pasan de Waterfall a Agile. Muchas organizaciones no pueden cambiar la gobernanza, los contratos y las herramientas de una sola vez. Lo híbrido es un escalón legítimo, siempre que el estado final sea una decisión y no una deriva.
• Proveedores y clientes con ritmos distintos. Si un cliente revisa los entregables cada mes y el equipo trabaja en sprints quincenales, las cadencias híbridas mantienen honestas a ambas partes.

PMI reporta que el uso de lo híbrido subió del 20% al 31% entre 2020 y 2023, por lo que ya no es una elección inusual.

Si su proyecto es pequeño, el alcance es estable y nadie pide puertas de control, opte por Waterfall puro o Agile puro. Lo híbrido añade costo de coordinación, y solo debe pagarlo cuando necesite lo que ofrece.

Cómo configurar un proyecto híbrido, paso a paso

Paso 1: Liste las restricciones fijas

Anote todo lo que no puede moverse: la fecha de lanzamiento, el tope del presupuesto, los puntos de control regulatorios, los entregables contractuales, los plazos fijos de los proveedores. Estos son sus anclas predictivas.

Paso 2: Liste las incógnitas

A continuación, enumere lo que honestamente aún no puede saber. Preferencias de los usuarios, viabilidad técnica, desempeño de los proveedores, el conjunto exacto de funcionalidades. Un pre-mortem es una forma rápida de sacar a la luz incógnitas que el equipo de otro modo ignoraría, y el cono de la incertidumbre es un recordatorio útil de que las estimaciones al inicio de un proyecto son naturalmente amplias.

Paso 3: Divida el trabajo en predictivo y adaptativo

Recorra el desglose del trabajo y etiquete cada fase o flujo de trabajo como predictivo, adaptativo o mixto. Regla práctica: si pudiera escribir hoy los criterios de aceptación y esperar que se mantengan, es predictivo. Si los criterios dependen de un feedback que aún no ha reunido, es adaptativo.

Paso 4: Defina las fronteras

Este es el paso que la mayoría de los equipos omite, y es donde aplica la advertencia de Forrester. Para cada traspaso entre una parte predictiva y una adaptativa, anote:

• Lo que recibe el equipo adaptativo (un objetivo y restricciones, no una especificación de 200 páginas).
• Lo que se le permite cambiar y quién aprueba los cambios mayores.
• Lo que devuelve al proceso predictivo (una demo, un build, un informe de pruebas).
• Qué tan rápido puede absorber ese resultado el proceso de lanzamiento.

Paso 5: Elija la cadencia y las ceremonias

Defina la cadencia de sprint o de flujo para el trabajo adaptativo y el calendario de puertas o revisiones para el trabajo predictivo. Siempre que sea posible, aliníelos: si las revisiones de puerta ocurren cada mes, haga que una de cada dos revisiones de sprint sea una verificación de preparación para la puerta. Use el timeboxing para que el trabajo de las iteraciones no se extienda hasta llenar el calendario de puertas.

Paso 6: Planifique por olas sucesivas

Detalle el corto plazo y mantenga grueso el largo plazo. La planificación por olas sucesivas es una opción natural: el roadmap comprometido se mantiene a nivel de hitos, mientras que las siguientes una o dos iteraciones se planifican en detalle.

Paso 7: Acuerden un único conjunto de métricas

El trabajo predictivo suele reportar variación de cronograma y de costo. El trabajo adaptativo reporta velocity o throughput y burndown. Elija un conjunto pequeño y compartido que los ejecutivos puedan leer sin traducción, como hitos cumplidos, alcance entregado frente al planificado y riesgos abiertos.

Paso 8: Revise y ajuste la mezcla

En cada puerta, pregunte si la división sigue siendo adecuada. Quizá una fase que creía predictiva sigue cambiando, o un área adaptativa se ha estabilizado. Mueva la línea. Un híbrido debe afinarse, no congelarse.

Plantilla de plan de proyecto híbrido

Copie esto en un documento o una hoja de cálculo y complételo por proyecto. Una fila por fase o flujo de trabajo.

Añada una sección de fronteras debajo:

Ejemplos de lo híbrido por función de negocio

Software y TI. Una empresa que reemplaza su sistema de facturación fija la fecha de migración y el plan de migración de datos (predictivo), mientras el equipo construye los nuevos flujos de facturas en sprints y los prueba con usuarios de finanzas cada dos semanas.

Marketing. Un lanzamiento de producto tiene una fecha fija, un presupuesto aprobado y una revisión legal de las afirmaciones. El contenido, la creatividad publicitaria y las landing pages se ejecutan en sprints semanales. La aprobación legal y la compra de medios siguen pasos con puertas.

Operaciones e instalaciones. Abrir un nuevo almacén exige un calendario de permisos, la entrega de equipos y el acondicionamiento en secuencia. Los flujos de inventario y escaneo dentro de él se configuran de forma iterativa, se prueban en un pasillo y luego se amplían.

RR. HH. Implantar un nuevo proceso de desempeño sigue un calendario ligado al ciclo de evaluación y a las aprobaciones de políticas. Los formularios, la capacitación de gerentes y las comunicaciones se perfeccionan mediante grupos piloto.

Desarrollo de productos. Un fabricante usa stage gates para liberar financiamiento. Entre puertas, los ingenieros iteran sobre prototipos y los resultados de las pruebas moldean el caso de negocio de la siguiente puerta. Para el lado de la verificación de este tipo de trabajo, consulte el modelo V.

Ventas y customer success. Una migración de CRM tiene una fecha de fin de contrato fija para el sistema anterior. La limpieza de datos es predictiva, mientras que los dashboards, los playbooks y las reglas de enrutamiento se ajustan en ciclos cortos con los equipos que los usan.

Qué hacer y qué evitar en la gestión de proyectos híbrida

Qué hacer

• Decida la división a propósito. Anote qué partes son predictivas y cuáles adaptativas, y por qué.
• Gestione primero las fronteras. Los traspasos son donde fallan los híbridos, así que dedique allí su esfuerzo de diseño.
• Dé autoridad real a los equipos adaptativos dentro de las restricciones. De lo contrario, es Waterfall con stand-ups.
• Mantenga proporcional la gobernanza. Las puertas deben verificar resultados y riesgos, no exigir los mismos documentos para cada sprint.
• Use un lenguaje compartido. Acuerden términos como "terminado", "hito" y "lanzamiento" para que ambas partes entiendan lo mismo.
• Revise la mezcla en cada puerta y mueva la línea cuando la evidencia lo indique.

Qué evitar

• No acople un stand-up diario a un plan fijo y lo llame Agile. Los rituales sin flexibilidad no cambian nada.
• No congele los requisitos en la fase water para luego pedir a los sprints que se "adapten". El feedback del sprint no tiene adónde ir.
• No acumule el resultado de los sprints detrás de un lanzamiento trimestral. Se pierde el beneficio de las entregas frecuentes.
• No mantenga dos sistemas de reportes que los ejecutivos tengan que conciliar por sí mismos.
• No use "híbrido" como excusa para evitar una decisión. Si no puede decir qué es fijo y qué es fluido, aún no ha diseñado un híbrido.
• No añada complejidad híbrida a un proyecto pequeño y estable que un solo método manejaría sin problemas.

Desafíos comunes y cómo manejarlos