Un equipo puede tener reuniones diarias, tablero Kanban y sprints de dos semanas y, aun así, no trabajar de forma ágil.
La agilidad no depende de usar palabras como sprint, backlog o retrospectiva. Depende de reducir el tiempo entre una decisión, una entrega y el aprendizaje que provoca. Al terminar esta ficha podrás distinguir una práctica ágil real de una simple colección de ceremonias.
Objetivo didáctico
Al terminar esta ficha serás capaz de coordinar un proyecto mediante principios ágiles, seleccionar prácticas de Scrum o Kanban según el tipo de trabajo y facilitar decisiones de planificación, priorización y mejora en equipos que enfrentan cambios frecuentes.
Introducción
Coordinar trabajo complejo exige algo distinto de construir un plan detallado y defenderlo hasta el final. Cuando cambian las necesidades del cliente, aparecen dependencias o una hipótesis resulta equivocada, el valor de un equipo está en detectar el cambio temprano y responder antes de haber invertido meses en la dirección incorrecta.
Las metodologías ágiles organizan esa capacidad mediante ciclos cortos, transparencia del trabajo, retroalimentación frecuente y adaptación. No eliminan la planeación: la distribuyen a lo largo del proyecto. En lugar de apostar todo a una gran decisión inicial, el equipo convierte cada entrega en nueva información para decidir el siguiente paso.
📐 Concepto: agilidad
Capacidad de generar valor en incrementos pequeños, obtener retroalimentación y modificar el rumbo con un costo razonable. Scrum estructura ciclos de inspección y adaptación; Kanban gestiona el flujo continuo y limita el trabajo en proceso.
Para una persona coordinadora, dominar agilidad implica decidir qué problema requiere Scrum, cuál se beneficia de Kanban y qué prácticas pueden combinarse sin convertir el método en una colección incoherente de reuniones. También implica proteger al equipo de la sobrecarga mientras mantiene visibles los compromisos.
Esta ficha recorre los valores ágiles, la arquitectura mínima de Scrum, el flujo de Kanban, la planificación y retrospectiva, la gestión del backlog y la aplicación fuera de equipos de software. El foco no es memorizar vocabulario: es usarlo para tomar mejores decisiones de coordinación.
Desarrollo del tema
Principios del manifiesto ágil
En febrero de 2001, diecisiete profesionales del desarrollo de software se reunieron en Snowbird, Utah, y redactaron el Manifiesto Ágil. El documento condensó cuatro valores y doce principios. Su aportación fue desplazar el énfasis desde procesos rígidos hacia personas, resultados utilizables, colaboración y respuesta al cambio (Beck et al., 2001).
Los cuatro valores no dicen que procesos, documentación, contratos o planes carezcan de valor. Dicen que, cuando existe tensión, el elemento de la izquierda merece mayor atención. Para un coordinador esto significa que un cronograma no debe tener más autoridad que la evidencia de que una prioridad dejó de ser relevante.
En un proyecto de lanzamiento comercial en Monterrey, por ejemplo, el equipo puede haber programado seis semanas de materiales impresos. Si en la segunda semana el canal principal cambia a comercio electrónico, mantener el plan original solo para “cumplir” sería administración del documento, no del proyecto.
La práctica accionable es formular en cada revisión dos preguntas: “¿qué evidencia obtuvimos desde la última decisión?” y “¿qué deberíamos cambiar a partir de ella?”. Esa disciplina convierte la adaptación en una decisión explícita y evita confundir flexibilidad con improvisación.
Scrum: roles, eventos y artefactos
Scrum organiza el trabajo alrededor de un equipo pequeño que persigue un objetivo común. La Guía Scrum 2020 define tres responsabilidades: Product Owner, Scrum Master y Developers. También establece cinco eventos —el Sprint y cuatro eventos contenidos en él— y tres artefactos principales: Product Backlog, Sprint Backlog e Incremento.
El Product Owner maximiza valor y ordena el backlog; el Scrum Master ayuda a que Scrum se entienda y funcione; y los Developers convierten elementos seleccionados en un incremento terminado. Ninguno equivale exactamente a “jefe de proyecto”, porque el modelo distribuye decisiones que en estructuras tradicionales suelen concentrarse.
Los eventos existen para crear cadencias de inspección. Sprint Planning decide qué se intentará lograr; Daily Scrum permite ajustar el plan; Sprint Review examina el resultado con interesados; y Retrospective mejora la manera de trabajar. Saltarse la inspección pero conservar las reuniones elimina la función principal del sistema.
En un equipo de comunicación institucional de ocho personas, Scrum puede utilizarse para producir una campaña en ciclos de dos semanas. El incremento no tiene que ser software: puede ser una versión completa de mensajes, piezas y calendario de publicación que ya pueda ser revisada por usuarios internos.
💫 Scrum combina solo 3 responsabilidades, 3 artefactos y una estructura pequeña de eventos.
La Guía Scrum 2020 redujo deliberadamente prescripciones: la estructura es ligera porque el método espera que el equipo resuelva gran parte del “cómo”.
Kanban: flujo visual y límites de trabajo en proceso
Kanban parte de una idea sencilla: no basta con saber cuánto trabajo existe; hay que saber dónde se acumula. Un tablero visual convierte el proceso en columnas como “por hacer”, “en proceso”, “en revisión” y “terminado”. La ubicación de cada tarjeta muestra el estado real del sistema.
El límite de trabajo en proceso o WIP establece cuántos elementos pueden permanecer simultáneamente en una etapa. Si una columna tiene límite 3 y ya contiene tres trabajos, el equipo no inicia un cuarto: primero ayuda a mover alguno de los existentes. La restricción expone cuellos de botella que antes quedaban ocultos.
En una agencia mexicana que administra solicitudes de diseño, tener veinte piezas “en proceso” puede significar que ninguna está cerca de terminar. Reducir el WIP a cuatro obliga a cerrar ciclos y hace más visible cuándo la aprobación del cliente, y no el diseño, está frenando el flujo.
La coordinación cambia de “¿quién está ocupado?” a “¿qué está impidiendo terminar?”. Ese giro es importante porque una persona al 100% de utilización puede generar más cola para las demás. El objetivo no es mantener a todos ocupados cada minuto, sino hacer que el trabajo valioso avance.
🧩 Clasifica cada señal según lo que conviene hacer.
Sprint planning y retrospectiva efectiva
Una buena planificación de Sprint no es una sesión para asignar tareas una por una. Su propósito es acordar un objetivo de Sprint, seleccionar trabajo coherente con ese objetivo y construir una primera idea de cómo abordarlo. Si el equipo sale únicamente con una lista de pendientes, falta una dirección compartida.
Una retrospectiva tiene otra función: observar el sistema de trabajo. No debería convertirse en una ronda de quejas ni en una búsqueda de culpables. El resultado útil es una mejora suficientemente pequeña para probarse durante el siguiente ciclo y suficientemente concreta para saber si funcionó.
En un Sprint de diez días laborales, un equipo puede comprometerse a reducir de 72 a 48 horas el tiempo de preparación de cotizaciones. En la retrospectiva descubre que la demora principal ocurre porque datos comerciales llegan incompletos; la mejora elegida puede ser una plantilla de entrada obligatoria.
La persona coordinadora facilita mejor estas conversaciones cuando distingue hechos, interpretaciones y acciones. Primero pregunta qué ocurrió; después qué explicación parece más probable; finalmente qué experimento se realizará. Esa secuencia reduce discusiones basadas únicamente en impresiones.
Gestión del backlog priorizado
El backlog es una lista ordenada de trabajo posible, no una promesa de realizarlo todo. Su calidad depende tanto de lo que contiene como de la facilidad con que permite decidir qué no hacer todavía. Un backlog de 300 elementos sin revisión puede ser un almacén de deseos, no una herramienta de gestión.
Priorizar implica considerar valor, urgencia, riesgo, dependencia y aprendizaje. Dos iniciativas con esfuerzo similar pueden tener prioridad distinta si una desbloquea cuatro trabajos posteriores o permite validar una hipótesis crítica. El orden debe poder explicarse sin depender de quién habla más fuerte.
En una empresa de servicios de Querétaro, por ejemplo, corregir un error que afecta la facturación de 20% de los clientes puede anteceder a una mejora visual solicitada por dirección. La decisión no desobedece a la dirección: traduce la estrategia a una secuencia defendible.
Una práctica útil es revisar semanalmente los primeros diez elementos y mensualmente el resto. Los primeros deben estar suficientemente entendidos; los lejanos pueden permanecer más amplios. Refinar con el mismo detalle algo que quizá nunca se hará es una forma silenciosa de desperdicio.
Si todo lo que entra al backlog termina etiquetado como “alta prioridad”, ¿existe realmente una priorización?
Ágil en contextos no tecnológicos
Scrum y Kanban nacieron o se popularizaron en contextos tecnológicos, pero sus principios pueden adaptarse a marketing, recursos humanos, compras, capacitación, consultoría y operaciones. La pregunta útil no es “¿podemos usar Scrum?”, sino “¿nuestro trabajo se beneficia de ciclos de retroalimentación más cortos?”.
Una campaña de reclutamiento puede gestionarse por Sprints; una mesa de solicitudes administrativas puede beneficiarse más de Kanban continuo. Un proyecto de evento corporativo puede usar un backlog priorizado sin adoptar todos los eventos Scrum. Adaptar no significa quitar arbitrariamente piezas, sino entender primero qué problema resuelve cada práctica.
En una organización social de Ciudad de México, por ejemplo, un equipo puede dividir una campaña de donación en incrementos semanales: página de registro, mensajes iniciales, prueba con una comunidad pequeña y posterior ampliación. Cada entrega permite aprender antes de comprometer todo el presupuesto.
El nivel intermedio exige explicar esa adaptación al equipo. Cuando una práctica se incorpora, debe quedar claro qué problema intenta resolver, qué comportamiento se espera y qué señal indicará que ayudó. Si nadie puede responder esas tres preguntas, la práctica corre el riesgo de convertirse en ritual.
Conclusión
Coordinar con agilidad significa hacer visible el trabajo, entregar en ciclos que permitan aprender y proteger la capacidad del equipo para terminar. Scrum ofrece una cadencia estructurada; Kanban permite observar y mejorar el flujo. Ninguno sustituye el juicio de quien coordina.
El objetivo no es implantar una metodología “pura”, sino comprender qué problema resuelve cada elemento y preservar los principios de transparencia, inspección y adaptación. Un equipo verdaderamente ágil puede usar pocas herramientas; lo que no puede perder es la capacidad de aprender y ajustar.
🔭 Para seguir aprendiendo
- ¿Qué partes de Scrum perderían sentido si los ciclos de entrega fueran de seis meses?
- ¿Cómo cambia un sistema Kanban cuando la verdadera restricción está fuera del equipo?
- ¿Qué práctica ágil de tu organización existe por costumbre y no por una necesidad claramente definida?
Actividad de aprendizaje autónoma
Diseña un tablero ágil para un proyecto real
Selecciona un proyecto, campaña o flujo de trabajo de tu equipo que tenga entre 5 y 20 actividades abiertas. La evidencia final será un esquema de coordinación que pueda ponerse a prueba durante una semana o un Sprint.
- Define en una oración el resultado que el equipo necesita conseguir.
- Escribe entre 8 y 15 elementos de trabajo y ordénalos por valor o urgencia.
- Decide si el flujo se gestionará mejor por Sprint o de forma continua.
- Si usas Kanban, define columnas y al menos un límite WIP. Si usas Scrum, define duración del Sprint y objetivo.
- Establece una reunión o punto de revisión y una señal cuantitativa que permita evaluar el flujo.
- Después de una semana, registra una modificación basada en evidencia.
Si limitamos o reorganizamos podremos mejorar .
Evidencia de logro: el tablero permite saber qué está en curso, qué tiene prioridad, cuándo puede entrar nuevo trabajo y qué señal se revisará para decidir un ajuste.
Reflexión final: ¿qué parte de la forma actual de trabajar tendrías que dejar de hacer para que la agilidad produzca un cambio real?
Referencias recomendadas
Anderson, D. J., & Carmichael, A. (2016). Essential Kanban condensed. LeanKanban University Press.
Beck, K., et al. (2001). Manifesto for Agile Software Development.
Schwaber, K., & Sutherland, J. (2020). The Scrum Guide: The definitive guide to Scrum.