¿Scrum o Kanban? Una forma práctica de elegir lo que conviene
A mediados de 2021, muchos equipos llevaban un año trabajando desde la mesa de la cocina o un cuarto improvisado, y bastantes recurrieron a un marco ágil para mantener la entrega firme mientras todo lo demás se tambaleaba. La pregunta más frecuente era sencilla: ¿hacemos Scrum o Kanban? La respuesta honesta es que no son rivales. Scrum es un marco con roles, eventos definidos y un Sprint de duración fija; Kanban es un método para visualizar y limitar el trabajo en curso de modo que fluya. Elegir bien empieza por entender el trabajo que se tiene delante, no por escoger un bando.
Cómo se ve hacerlo bien
Los buenos equipos eligen el enfoque que encaja con la forma de su trabajo. Un equipo de producto que avanza hacia una meta y puede comprometerse con un lote acotado de trabajo durante una o dos semanas suele prosperar con Scrum: el Sprint crea un ritmo estable, la Revisión de Sprint ofrece un punto de control regular a las partes interesadas y la Retrospectiva obliga a una mejora honesta. Un equipo que atiende un flujo constante de solicitudes impredecibles —soporte, operaciones, respuesta a incidentes— suele rendir mejor con Kanban, donde los límites de trabajo en curso evitan la sobrecarga y el tiempo de ciclo se vuelve la métrica que importa.
Scrum elegido porque el equipo puede sostener un Objetivo de Sprint durante el Sprint, no porque a la dirección le guste la palabra
Kanban elegido con límites de trabajo en curso explícitos y una política de cómo avanzan los elementos, no solo un tablero con notas adhesivas
Una definición de terminado clara en ambos casos, para que «hecho» signifique lo mismo para todos
Métricas usadas para aprender —tendencias de velocidad en Scrum, tiempo de ciclo y rendimiento en Kanban— y no para clasificar a las personas
Cómo se ve hacerlo mal
Las adopciones fallidas suelen compartir una señal: el equipo copió las ceremonias pero se saltó su propósito. Hemos visto equipos «Scrum» cuyo backlog cambia a mitad del Sprint un día sí y otro también, lo que destruye el foco que el Sprint existe para proteger. Hemos visto tableros «Kanban» con cuarenta tarjetas en la columna En curso y ningún límite, que no son más que una lista de tareas pintada de tres colores. En ambos casos se culpa al marco cuando el problema real es que nadie cambió cómo se toman las decisiones.
Scrum de fachada. Las reuniones diarias se convierten en informes de estado para un jefe, falta el Objetivo de Sprint y el Sprint pasa a ser una cuenta atrás en vez de un compromiso.
Kanban sin límites. El tablero visualiza el trabajo pero no fija límites de trabajo en curso; se empieza todo y se termina poco, y el flujo nunca mejora porque nada lo restringe.
Teatro del marco. El equipo ejecuta cada evento al pie de la letra pero trata la Retrospectiva como opcional, así que los mismos problemas se repiten Sprint tras Sprint.
Una prueba útil: si tu trabajo llega en ráfagas impredecibles y las prioridades cambian cada hora, la cadencia de un Sprint te peleará, y el flujo continuo de Kanban será más amable. Si tu equipo necesita una meta común y tiempo protegido para alcanzarla, la estructura de Scrum se gana su lugar. Muchos equipos maduros terminan mezclando ambos —celebran los eventos de Scrum mientras aplican límites de trabajo en curso a su flujo— pero se ganan esa mezcla dominando primero uno de los dos.
Tanto si estás formando un equipo de entrega por primera vez como si estás desenredando un marco que dejó de servirte, la asesoría de entrega de programas y proyectos de XNM puede ayudarte a elegir y dirigir el enfoque que encaja con tu trabajo.