Las Tres Opciones Reales

Scrum funciona mejor cuando tu equipo entrega funcionalidades con una cadencia predecible. Los sprints de dos semanas fuerzan una conversación de planificación cada catorce días, una demo que hace visible el progreso y una retrospectiva que saca a la luz la fricción antes de que se solidifique. Obtienes roles definidos — un product owner que cuida el backlog, un scrum master que cuida el proceso y desarrolladores que cuidan el compromiso.

La estructura es el punto. Los equipos de producto que construyen hacia objetivos trimestrales necesitan el ritmo de "planificamos estos ocho tickets, terminamos siete, aquí está el porqué". Los stakeholders obtienen pronósticos basados en la velocidad histórica en lugar de suposiciones optimistas. Los desarrolladores obtienen permiso para decir "eso no está en este sprint" sin una pelea política.

El costo de Scrum es la rigidez. Los cambios de alcance a mitad del sprint son costosos. Las ceremonias toman tiempo real de calendario — un equipo de seis personas pasará 4–6 horas por sprint en rituales. Si tu trabajo es impulsado por interrupciones o tus prioridades cambian diariamente, esa rigidez se convierte en lastre en lugar de apalancamiento.

Kanban optimiza el rendimiento en entornos donde el trabajo no esperará el límite de tu sprint. Un ticket de soporte escalado a las 2 PM no le importa que tu planificación de sprint no sea hasta el jueves. Kanban dice: visualiza el trabajo, limita cuánto está en progreso a la vez y toma el siguiente elemento de mayor prioridad cuando se libere capacidad.

El tablero es el sistema. Las columnas representan etapas (Por Hacer, En Progreso, Revisión, Hecho), y los límites WIP limitan cuántos tickets pueden estar en cualquier columna simultáneamente. Un equipo de 3 personas con un límite WIP de 4 en "En Progreso" no puede iniciar trabajo nuevo hasta que algo avance. Esa restricción es lo que hace que Kanban sea más que una lista de tareas — obliga al equipo a terminar antes de comenzar.

Kanban se adapta a equipos de operaciones, equipos de plataforma y cualquier grupo cuyo trabajo entrante sea impredecible en tiempo pero relativamente uniforme en tamaño. También funciona bien como un paso intermedio — los equipos inseguros sobre Scrum pueden ejecutar Kanban durante un mes para construir hábitos de flujo antes de agregar sprints.

No todos los equipos necesitan una metodología ahora mismo. Un equipo de 3 personas sentadas en la misma sala, entregando un producto, con un backlog corto y conversación diaria — ese equipo ya tiene ciclos de retroalimentación. Agregar ceremonias de sprint o tableros Kanban encima no crea valor; crea sobrecarga por el bien de la sobrecarga.

Los fundamentos de este curso — disciplina de control de código fuente, tickets significativos, estimación básica y un entendimiento compartido de qué significa "hecho" — son suficientes para entregar bien para equipos donde el costo de coordinación es bajo. La señal de que necesitas más estructura no es "leímos sobre Scrum y suena profesional". Es dolor concreto: traspasos perdidos, sorpresas crónicas en el momento de la demo, trabajo que permanece inactivo porque nadie sabía que estaba bloqueado, o nuevos miembros del equipo que no pueden integrarse sin una semana de seguimiento.

Si esos problemas no están ocurriendo, quédate aquí. Revisa esta decisión en tres meses o cuando el equipo crezca más allá de cinco.