Modo rojo vs. modo verde: velocidad o contexto en SDD
El trade-off más frecuente al adoptar SDD: ¿invierto en documentar bien o entrego rápido? Cómo definir dos modos de trabajo claros para no tener que decidirlo ticket a ticket.
El trade-off que paraliza equipos
El obstáculo más frecuente al intentar adoptar SDD en un equipo real no es técnico: es la percepción de que documentar bien requiere tiempo que no hay. Y la percepción es correcta — documentar bien sí requiere tiempo. Lo que no es correcto es asumir que ese tiempo siempre tiene que salir del mismo sprint que la entrega.
El error conceptual está en tratar el trade-off como una decisión binaria: o SDD completo o nada. La respuesta más útil es definir dos modos de trabajo explícitos — modo rojo y modo verde — que el equipo puede activar conscientemente según el contexto, sin tener que justificarlo ticket a ticket.
Modo rojo
Velocidad primero. Documentación mínima. Deuda de contexto anotada.
Modo verde
Reproducibilidad primero. Spec completa antes del código.
Modo rojo: entrega primero
El modo rojo se activa cuando la entrega no puede esperar. Las características que lo definen:
En modo rojo se entrega con la documentación mínima necesaria — suficiente para que otro desarrollador entienda qué se hizo y por qué. La deuda de contexto se anota explícitamente como un ticket en el backlog, con prioridad para el siguiente sprint disponible. No se ignora: se aplaza con conciencia.
Modo verde: reproducibilidad primero
El modo verde se activa cuando la funcionalidad merece inversión de contexto. Las características que lo justifican:
En modo verde se invierte en la spec completa antes de tocar el código. El agente recibe un contexto suficientemente rico como para producir código de calidad en la primera iteración, y cualquier miembro del equipo puede replicar o extender la funcionalidad sin depender de quien la implementó originalmente.
Cómo decidir el modo en equipo
La decisión del modo no debe tomarla una sola persona. En el grooming o en la planificación del sprint, el equipo responde estas preguntas en conjunto:
¿Cuántas veces vamos a implementar algo similar a esto?
Más de una vez → modo verde justificado
¿Puede un agente ejecutar este ticket solo con la spec actual?
Si la respuesta es no → modo verde
¿Tenemos fecha fija con penalización?
Sí → modo rojo, pero anotar la deuda de contexto
¿Qué pasa si el desarrollador que lo sabe todo se va del equipo mañana?
Si el equipo quedaría bloqueado → modo verde urgente
Anti-patrón: modo rojo permanente
El modo rojo es una herramienta legítima para situaciones de presión real. El problema surge cuando un equipo entra en modo rojo de forma permanente — ya no por presión externa, sino porque es el estado por defecto.
Los equipos que siempre están en modo rojo acumulan deuda de contexto sprint a sprint. El síntoma más claro es que cada sprint se vuelve más lento que el anterior: el agente no mejora porque nunca recibe suficiente contexto, los bugs tardan más en resolverse porque nadie recuerda el razonamiento detrás del código, y cada nuevo miembro necesita semanas para entender cómo funciona el sistema.
El síntoma de alarma: si el equipo lleva más de tres sprints consecutivos en modo rojo sin haber pagado ninguna deuda de contexto, no es una situación de emergencia — es el proceso habitual disfrazado de emergencia. El modo rojo permanente no es una estrategia: es el síntoma de que no hay estrategia.
¿Quieres aplicar esto en tu equipo?
En Kuuli Technologies llevamos estas metodologías a equipos reales. Escríbenos si quieres una sesión de trabajo o una consultoría sobre agentes IA y SDD.