Cuando la cascada se encontró con lo ágil: una historia de entrega híbrida
Un organismo público de tamaño medio contrató a un proveedor para reemplazar un sistema de permisos obsoleto. El contrato era de precio fijo con plazos regulatorios estrictos: condiciones clásicas para un plan en cascada. Pero los requisitos eran realmente difusos: nadie podía describir del todo cómo debían comportarse los nuevos flujos de trabajo hasta verlos. El equipo, repartido en tres ciudades y trabajando de forma remota tras los cierres de oficinas del año anterior, decidió combinar ambos mundos. Así fue ese híbrido y lo que les enseñó. Los nombres y detalles se han cambiado.
Cómo dividieron el trabajo
El equipo mantuvo una columna vertebral en cascada para lo que de verdad no podía moverse: la fecha de puesta en marcha regulatoria, la ventana de migración de datos y la barrera de acreditación de seguridad. Estos se convirtieron en hitos fijos en un cronograma maestro, cada uno con un responsable claro y una fecha que todos trataban como real.
Dentro de esa columna, la construcción se desarrolló en sprints de dos semanas. El dueño de producto —un analista sénior del organismo, no del proveedor— mantenía un único backlog priorizado. Cada quincena el equipo mostraba software funcional a los empleados de permisos reales, quienes luego daban forma al siguiente sprint. Las fechas fijas indicaban a todos dónde tenía que llegar el tren; los sprints decidían qué se cargaba en cada vagón.
Lo que casi salió mal
El híbrido no fue fluido al principio. Tres problemas aparecieron pronto, y son los que enfrentan la mayoría de los proyectos híbridos.
Dos lenguajes de informe. El comité directivo quería el porcentaje de avance frente al plan, mientras que el equipo medía el progreso en incrementos funcionales. Durante dos meses los informes de estado se contradecían. Lo resolvieron vinculando los elementos del backlog completados con el hito que alimentaban, de modo que un solo gráfico servía a ambos públicos.
Un alcance congelado que no lo estaba. Como el contrato era de precio fijo, cada cambio parecía una pelea. El equipo introdujo un protocolo de cambio ligero: los pequeños ajustes dentro de un sprint eran gratuitos, pero todo lo que tocara un hito fijo pasaba por una breve revisión de impacto documentada. Esa única regla redujo la fricción de forma drástica.
El silencio remoto. Trabajando en tres ciudades, el equipo confundió el silencio con el acuerdo. Un desarrollador pasó una semana construyendo la regla de validación equivocada porque una decisión tomada en el chat nunca le llegó. Trasladaron las decisiones clave a un registro escrito y consultable, e hicieron de la reunión diaria el lugar donde los obstáculos se nombraban en voz alta.
Las lecciones que vale la pena tomar
Para la puesta en marcha, el sistema se entregó en la fecha regulatoria con las funciones que los empleados realmente necesitaban, y las inevitables concesiones recayeron en los elementos de menor prioridad y no en los exigidos por ley. En retrospectiva, el equipo atribuyó el éxito a un puñado de hábitos que cualquier proyecto híbrido puede copiar.
Sea explícito sobre qué partes son fijas y cuáles flexibles, y nunca deje que esa frontera se difumine.
Mantenga un solo backlog y un solo responsable que decida la prioridad, aun cuando el cronograma se rija por hitos.
Traduzca el avance en una sola imagen compartida para que ejecutivos y equipo lean la misma realidad.
Haga que el cambio sea barato dentro de un sprint y deliberado cuando toque una fecha fija.
En un equipo remoto, deje las decisiones por escrito; el acuerdo verbal se evapora.
La entrega híbrida no es un compromiso que no contenta a nadie. Hecha con intención, permite honrar compromisos fijos mientras se descubre la solución correcta sobre la marcha, que es justo lo que este proyecto necesitaba.
Si está equilibrando plazos fijos con requisitos inciertos y quiere un enfoque de entrega que se ajuste a la realidad del trabajo, la asesoría en entrega de programas y proyectos de XNM puede ayudarle a diseñarlo y ejecutarlo.