METODOLOGÍA

Agile

Una familia de prácticas de desarrollo de software que prioriza iteraciones cortas, feedback frecuente del cliente y ajustar el plan según lo que el trabajo revela.

Última revisión: porKevin Riedl wiki ↗

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.

// FAQ

Preguntas frecuentes

Scrum de teatro: standups que son status reports, retros sin acciones, sprint planning sin sprint goal y demos canceladas la mitad de las veces. La cadencia se convierte en el objetivo y nadie pregunta si el cliente quiere lo que se está construyendo. Llamarlo «agile» no lo es.
No. Necesitas a alguien (puede ser el tech lead, el PM o el founder) que defienda la disciplina de plan-build-demo y reduzca fricción. La certificación no cambia esa habilidad. En la mayoría de startups por debajo de 15 personas, contratar un Scrum Master dedicado es overhead disfrazado de mejora de proceso.
Pregunta equivocada. La pregunta real es: ¿cuánto cambia la realidad mientras construyes? Si el dominio es estable y los requisitos son claros (raro), waterfall puede funcionar. Si lo que aprendes esta semana cambia lo que hay que hacer la siguiente (la mayoría), agile no es opcional. Híbridos honestos también existen.