Agile

Agile es más viejo de lo que la mayoría cree (el manifiesto es de 2001) y peor implementado de lo que la mayoría de equipos admite. La idea original era simple: planificar más allá de lo que puedes predecir es trabajo desperdiciado, así que planifica corto, envía, aprende, replanifica. Todo lo demás (Scrum, Kanban, SAFe, sprints, retros, story points) son detalles de implementación apilados encima.

La pregunta más útil para un equipo que dice «hacemos agile» es: ¿cuándo fue la última vez que el plan cambió por lo que se envió la semana pasada? Si la respuesta es nunca, el equipo hace cascada en trozos de dos semanas.

Ejemplo de la diferencia: dos equipos corren sprints de dos semanas. El Equipo A hace demo, ve que la feature que nadie del roadmap predijo es la que los usuarios de verdad clican, y reordena el siguiente sprint en torno a ella. El Equipo B hace demo, anota el feedback en un doc, y sigue con el plan que escribió en enero porque el plan es el plan. El Equipo A es agile. El Equipo B tiene ceremonias agile y cerebro de cascada. Las ceremonias son idénticas; solo difiere la disposición a actuar sobre la evidencia, y eso es todo el partido.

El trade-off honesto y el error de founder: agile no es licencia para saltarse la planificación, y no es gratis. Cambia previsibilidad a largo plazo por aprendizaje rápido, que es exactamente lo equivocado cuando el alcance, la regulación o un contrato de interfaz genuinamente no pueden cambiar (dispositivos médicos certificados, aviónica, cierto hardware). Incluso ahí los principios originales aplican dentro del equipo; el proceso de cara al público solo se parece más a cascada. Wavect es agile en el sentido original: trabajamos en ciclos cortos, hacemos demos a menudo, nos apoyamos en CI/CD para que enviar sea barato, y estamos dispuestos a tirar el trabajo que resulta estar equivocado. Somos escépticos con la versión de agile de la industria de certificaciones, donde la cadencia de reuniones se vuelve el objetivo y una suite de TDD se escribe para aparentar en vez de para tener confianza.

Cuándo importa esto en un proyecto de software. Cuando el alcance todavía puede cambiar porque el mercado te sigue enseñando algo, que es la situación de la mayoría de productos tempranos. Agile cambia previsibilidad a largo plazo por aprendizaje rápido, y ese cambio solo compensa si de verdad estás dispuesto a actuar sobre lo que se envía.

Qué suelen hacer mal los founders. Compran las ceremonias y conservan una mente en cascada: sprints de dos semanas, story points, retros, y un plan que no ha cambiado desde enero. Ceremonias sin disposición a cambiar de rumbo ante la evidencia son cascada disfrazada.

Cómo lo maneja Wavect. Somos agile en el sentido original: ciclos cortos, demos frecuentes, envíos baratos vía CI/CD, y tiramos el trabajo que resultó estar mal. Cuando el alcance genuinamente no puede moverse, lo decimos y planificamos en consecuencia; la guía de precio fijo vs time and materials cubre esa elección de contrato.