Adiós, Agile. Por qué dejé los Sprints y qué uso en su lugar.
Las metodologías ágiles se convirtieron en un teatro de productividad para mis proyectos. Descubre por qué las abandoné y el sistema más simple que uso ahora para construir y lanzar productos de verdad.
La trampa en la que todos caemos
Yo también fui un converso. Leí el manifiesto, me certifiqué como Scrum Master y llené pizarras (físicas y virtuales) con post-its de colores. Vendí la idea a mis equipos y a mis clientes: sprints de dos semanas, *daily stand-ups*, retrospectivas, *planning poker*... la promesa de un ciclo virtuoso de entrega continua y mejora constante.
Y durante un tiempo, pareció funcionar. Pero lentamente, casi sin darme cuenta, la metodología se convirtió en el producto. El objetivo ya no era entregar valor al usuario, sino completar el sprint. El éxito no se medía en la satisfacción del cliente, sino en la *velocity* del equipo.
Las reuniones diarias se transformaron en reportes de estado para el manager de turno. Las retrospectivas, en sesiones de quejas sin acción. Y la planificación, en un ejercicio tedioso de estimaciones ficticias sobre tareas que nadie entendía del todo. Estábamos haciendo "teatro de productividad": parecíamos muy ocupados, pero el progreso real era lento y doloroso.
El problema no es "ágil", es "Agile™"
El espíritu original de ser ágil —responder al cambio, colaborar, entregar software funcional— es fantástico. El problema es el corsé industrial que se ha construido alrededor: Agile con mayúsculas.
Para un emprendedor o un equipo pequeño/mediano, este sistema es a menudo contraproducente:
* Mata el foco: Los sprints de dos semanas son demasiado cortos para abordar problemas complejos. Generan un ciclo constante de empezar y parar, matando el *deep work* y el estado de *flow*. * Genera burocracia: La gestión de backlogs, la puntuación de tareas y el mantenimiento de JIRA o Asana se convierten en un trabajo a tiempo completo. Es tiempo que no se dedica a diseñar, programar o hablar con usuarios. * Crea una falsa sensación de progreso: Mover tarjetas en un tablero es satisfactorio, pero no equivale a progreso real. Es fácil engañarse pensando que se avanza mucho cuando solo se están completando tareas pequeñas y desconectadas.
Decidí que tenía que haber una forma mejor. Una que priorizara la calma, el foco y la entrega de valor tangible.
Mi alternativa: Ciclos de 6 semanas y autonomía real
No inventé la rueda. Mi sistema está fuertemente inspirado en la metodología "Shape Up" de Basecamp, pero adaptada a mi realidad. La he simplificado a sus componentes esenciales.
Así es como funciona:
1. Definimos el "Apetito" (1-2 semanas previas)
Antes de empezar a construir, un grupo muy pequeño (normalmente yo y un diseñador/líder técnico) define qué problema vamos a resolver en el próximo ciclo. No creamos un backlog detallado. En su lugar, definimos el "apetito": ¿cuánto tiempo estamos dispuestos a invertir en esta idea? La respuesta es siempre seis semanas.
Con ese límite, perfilamos la solución a un nivel de borrador. Bocetos, esquemas, pero nunca un desglose de tareas minucioso. El objetivo es tener una idea clara del "qué" y el "porqué", dejando el "cómo" al equipo que lo construirá.
2. El Ciclo de Construcción (6 semanas de foco)
Una vez empieza el ciclo, el equipo tiene autonomía total para construir la funcionalidad definida.
* No hay sprints. El plazo es de seis semanas. * No hay *daily stand-ups*. La comunicación es asíncrona (usamos Slack o Teams) y se basa en la confianza. Si alguien está bloqueado, lo dice. No necesitamos una ceremonia diaria para enterarnos. * El alcance es flexible, el tiempo no. Si el equipo ve que no puede construir la versión "perfecta" en seis semanas, tienen la autoridad para recortar funcionalidades secundarias. El objetivo es entregar una versión funcional y valiosa de la idea principal al final del ciclo. A esto lo llamamos "desbastar" la solución hasta su núcleo.
3. El Enfriamiento (2 semanas de libertad)
Después de las seis semanas de trabajo intenso, nos tomamos dos semanas de "enfriamiento" (*cooldown*).
Este tiempo no tiene un plan fijo. El equipo puede usarlo para:
* Corregir bugs importantes que hayan surgido. * Pagar deuda técnica. * Explorar ideas nuevas y prototipar. * Simplemente trabajar a un ritmo más relajado.
Este parón es clave. Evita el agotamiento (*burnout*) y permite que la creatividad fluya sin la presión de una fecha de entrega.
Ciclo Total: 8 Semanas[ 1-2 semanas de Shaping (Definición) ] --> [ 6 semanas de Building (Construcción) ] --> [ 2 semanas de Cooldown (Enfriamiento) ]
¿Por qué me funciona?
Este enfoque me ha devuelto la cordura y ha mejorado drásticamente la calidad y la velocidad de nuestros lanzamientos.
* Fomenta el trabajo profundo: Los ciclos largos permiten a los desarrolladores y diseñadores sumergirse en los problemas sin las constantes interrupciones de las ceremonias ágiles. * Entrega valor real: Al final de cada ciclo, tenemos una funcionalidad completa y significativa, no un puñado de tareas inconexas. * Reduce las reuniones a la mitad (o más): Menos tiempo hablando de trabajar, más tiempo trabajando. * Promueve la responsabilidad: Da al equipo la confianza y la autoridad para tomar decisiones reales sobre el producto.
No estoy diciendo que Agile sea inútil para todos. En grandes corporaciones con múltiples dependencias, puede que siga teniendo sentido. Pero si eres un equipo construyendo un producto, te animo a cuestionar el dogma.
El objetivo no es ser "ágil", es entregar software increíble. Y para mí, eso significó dejar Agile atrás.