Un Marco de Decisión

Los equipos que pueden describir el trabajo de la próxima semana hoy son candidatos para Scrum. Los equipos que no pueden describir el trabajo de mañana hoy son candidatos para Kanban.

Califícate en una escala del 1 al 5: 1 significa "tenemos un roadmap priorizado y la mayoría de los sprints van más o menos según lo planeado". 5 significa "la mitad de nuestro trabajo llega sin planificar: incidentes, escalaciones de clientes, solicitudes ad-hoc de otros equipos". La mayoría de los equipos de funcionalidades de producto se ubican en 1–2. La mayoría de los equipos de plataforma, DevOps y soporte se ubican en 4–5. Los equipos en 3 son genuinamente ambiguos, y "Scrumban" (cadencia de Scrum con pull estilo Kanban para trabajo no planificado) es una respuesta razonable para ellos.

La idea clave: la previsibilidad no se trata de disciplina. Un equipo puede ser extremadamente disciplinado y aún así tener trabajo impredecible porque el dominio lo exige. No confundas "no podemos predecir" con "no planificamos".

El sprint de Scrum es un compromiso de time-box: el equipo acepta proteger un período fijo de cambios de alcance. Eso solo funciona si la organización realmente respetará el límite.

Haz dos preguntas: ¿Puede tu product owner decir "no, eso espera hasta el próximo sprint" a un VP sin que lo anulen? ¿Y puede el equipo asistir de manera realista a la planificación, standup, revisión y retro en cada ciclo sin que esas ceremonias se cancelen por "algo más urgente"? Si ambas respuestas son sí, puedes sostener la cadencia de Scrum. Si alguna es no, los sprints colapsarán en flujo continuo con reuniones extra: lo peor de ambos mundos.

Kanban no requiere compromiso de cadencia. Aún puedes realizar retrospectivas y sesiones de planificación regulares, pero nada se rompe si omites una o la cambias por unos días. Para equipos en organizaciones que rutinariamente anulan planes, la falta de un límite de sprint en Kanban es honestidad, no descuido.

La estructura es andamiaje: compensa lo que el equipo aún no ha construido como memoria muscular. Un equipo de seis ingenieros que han trabajado juntos durante dos años podría no necesitar una definición formal de "listo" porque ya la han internalizado. Un equipo que se formó el mes pasado sí.

Señales concretas que apuntan hacia más estructura (Scrum):

• Más de dos ingenieros se unieron en el último trimestre
• El equipo no tiene un historial compartido de lo que significa "terminado"
• El trabajo regularmente se inicia sin criterios de aceptación claros
• Las retrospectivas revelan comunicación errónea repetida

Señales que apuntan hacia menos estructura (Kanban o solo fundamentos):

• El equipo tiene membresía estable y contexto compartido
• Los ingenieros se auto-organizan efectivamente sin asignaciones de roles
• Los elementos de trabajo son bien entendidos y relativamente uniformes
• El problema principal de coordinación es el rendimiento, no la alineación

Los equipos nuevos casi siempre se benefician de comenzar con más estructura y relajarla a medida que se construye confianza. Lo contrario —agregar estructura a un equipo que ya está luchando— se siente punitivo y genera resentimiento.

Scrum es un marco de todo o nada por diseño. No puedes ejecutar "medio sprint": o te comprometes con el time-box y las ceremonias, o no tienes Scrum. Adoptarlo significa cambiar cómo el equipo planifica, revisa y reflexiona en un solo movimiento. Esa es una transición de big-bang, y funciona mejor cuando el equipo está comprometido y un scrum master (o equivalente) está listo para guiar durante los primeros sprints difíciles.

Kanban es incremental por naturaleza. Comienzas visualizando tu flujo de trabajo actual en un tablero: aún no se requiere cambio de proceso. Luego agregas límites de WIP. Luego comienzas a medir el cycle time. Cada paso agrega valor de forma independiente. Si un paso no funciona, lo eliminas sin deshacer todo lo demás.

Para equipos escépticos del cambio de proceso o quemados por adopciones de metodología pasadas, el camino incremental de Kanban es de menor riesgo. Pruebas el valor en cada paso antes de comprometerte más. El enfoque de big-bang de Scrum es más rápido para la adopción completa, pero tiene una tasa de fracaso más alta en equipos que no están listos para el compromiso.

La metodología incorrecta es recuperable, pero el costo de recuperación varía. Un equipo que prueba Scrum durante dos sprints y decide que no encaja ha perdido un mes de ajuste y algo de buena voluntad. Un equipo que se reorganiza en torno a SAFe y compra herramientas empresariales tiene un camino de reversión mucho más difícil.

Evalúa tu costo de cambio honestamente: ¿Cuántas personas necesitan cambiar sus hábitos diarios? ¿Estás comprando herramientas o haciendo cambios en el organigrama para apoyar la metodología? ¿Se está reentrenando a los stakeholders externos sobre cómo interactuar con el equipo? Cuantos más puntos de contacto, mayor el costo de equivocarse, y más fuerte el argumento para comenzar con la opción más simple.

Para la mayoría de los equipos que hacen su primera elección de metodología, la respuesta es: comienza con Kanban (bajo compromiso, fácil de revertir) o Scrum (compromiso moderado, reversible en un sprint). No comiences con un marco de escalamiento. No comiences con algo que requiera coordinación entre equipos que aún no tienes. Ajusta el peso de la metodología al peso de la decisión.