IA · · ⏱ 6 min de lectura

El sprint que nadie duerme

Coordinar equipos de agentes autónomos con el vocabulario de Scrum y PMBOK: qué sobrevive de cada marco, qué se rompe, y qué queda por inventar.

Un equipo humano se reúne los lunes, discute el sprint, negocia el alcance, firma el acta y se va a casa. Un equipo de agentes autónomos no hace nada de eso. Y sin embargo alguien tiene que coordinarlo. Este artículo cruza Scrum y PMBOK por el mismo eje: cómo se coordinan tareas entre agentes que no comparten ni jornada, ni memoria, ni firma.

Un corredor humano pasa el testigo a una silueta que continúa la carrera hacia la noche
Alguien pasa el testigo. Alguien sigue corriendo cuando ya nadie mira.

Coordinar sin supervisar cada paso

Los protocolos que consolidamos en la industria —MCP, A2A— resuelven la capa de comunicación entre agentes. No resuelven la de coordinación. Que dos agentes puedan hablarse no dice nada sobre quién decide qué hace cada uno, cuándo pausan, cómo se sincronizan y quién responde cuando el resultado colectivo falla.

Y esa capa no está inventada desde cero. Existe, lleva medio siglo puliéndose sobre actores humanos, y ahora empieza a mirar hacia agentes. En junio de 2026, el PMI publicó The Standard for Artificial Intelligence in Portfolio, Program, and Project Management — el primer estándar global explícitamente diseñado para el problema. La 8ª edición del PMBOK ya integra IA de forma explícita. Y Gartner reportó un aumento del 1.445% en consultas sobre sistemas multi-agente entre Q1 2024 y Q2 2025. La disciplina se ha empezado a mover. La pregunta es hacia dónde.

Cómo se asigna el trabajo

Scrum asigna en el sprint planning: el PO presenta el backlog priorizado, el equipo estima esfuerzo, se compromete a un alcance. Conversacional y consensuado.

PMBOK asigna vía plan de gestión: alcance definido, WBS descompuesto, recursos asignados según matriz RACI. Documental y trazable.

Ninguno encaja limpiamente. Un agente no negocia esfuerzo —no tiene noción de fatiga ni velocity personal—. Un agente tampoco figura en una matriz RACI, porque no factura horas ni firma entregables.

Lo que sí sobrevive de cada marco:

  • De Scrum, el compromiso acotado en el tiempo: aunque no haya planning conversacional, el sistema necesita ventanas donde el trabajo se congela para poder evaluarse.
  • De PMBOK, la descomposición explícita de responsabilidades: alguien tiene que declarar qué agente puede hacer qué, con qué permisos, sobre qué recursos.

La primera es una decisión de operación. La segunda es de gobernanza. Ninguna sola basta.

Cómo se sincronizan las tareas

Scrum sincroniza vía ceremonias: daily, review, retrospective. Puntos fijos donde el equipo pausa, comparte estado y ajusta. Rítmico y humano.

PMBOK sincroniza vía informes de estado, hitos y control gates. Planificado y documental.

Con agentes, la primera diferencia es brutal: el agente no necesita pausar para sincronizarse. Comparte estado en cada intercambio, cada llamada de herramienta, cada actualización de memoria. La daily, diseñada para forzar visibilidad periódica que sin ella se dispersaría, se vuelve redundante cuando la visibilidad es continua por diseño.

Lo que sigue teniendo sentido —y aquí Scrum aporta algo real— es la retrospective. No como reunión, sino como bloque de tiempo donde el sistema evalúa qué hizo bien, qué hizo mal, y ajusta la política para el próximo ciclo. Es el único momento donde un sistema de agentes reflexiona sobre sí mismo con distancia. Y esa distancia, en un sistema que no duerme, no aparece sola: hay que diseñarla.

De PMBOK sobrevive algo complementario: los control gates como puntos donde escalar a supervisión humana antes de continuar. Un agente puede ejecutar mil decisiones autónomas. La decisión mil-uno, la que compromete presupuesto grande o dispara riesgo alto, tiene que pasar por un gate. No es una reunión — es un mecanismo de contención.

Cómo se cierra el trabajo

Scrum cierra con sprint review y definición de “done”. Iterativo y negociable.

PMBOK cierra con aceptación formal del entregable, firma y registro de lecciones aprendidas. Contractual y definitivo.

Aquí aparece el problema más incómodo. Un equipo de agentes puede producir un output sin que ningún agente esté en condiciones de firmarlo. La aceptación —el “done” scrum, el “sign-off” del PMBOK— presupone un actor con responsabilidad atribuible. Y en un sistema multi-agente, la responsabilidad es difusa por diseño.

Lo que Scrum aporta parcialmente es el incremento verificable: el resultado tiene que ser demostrable, no solo declarado. Que un agente reporte “tarea completada” no basta — se necesita evidencia observable. Y esa evidencia, cuando la genera otro agente, cae en el problema de la duda como infraestructura ya tratado en artículos anteriores de esta serie.

Lo que PMBOK aporta con más peso es la trazabilidad formal: para poder cerrar, tiene que quedar registro de qué se decidió, quién lo autorizó y sobre qué base. Ese registro, en un sistema donde los agentes no firman, se convierte en la única forma de reconstruir la responsabilidad después del hecho. No la localiza — la hace reconstruible.

Lo que cada marco aporta cuando el equipo no es humano

FunciónSobrevive de ScrumSobrevive de PMBOK
AsignaciónCompromiso acotado en el tiempoDescomposición explícita de responsabilidades
SincronizaciónRetrospective como pausa reflexiva diseñadaControl gates como puntos de escalado
CierreIncremento verificable con evidencia observableTrazabilidad formal reconstruible

Los dos marcos no compiten — resuelven capas distintas. Scrum aporta cadencia y ciclo. PMBOK aporta gobernanza y trazabilidad. Ninguno tal cual, ambos con lo que sobrevive de cada uno.

Lo que falta inventar

Adaptar mecánicamente Scrum o PMBOK a agentes es una respuesta insuficiente. Ambos marcos fueron diseñados para actores humanos, y esos actores tenían tres propiedades que un agente no tiene: jornada laboral, memoria personal y responsabilidad atribuible individualmente.

Un agente opera 24/7, sin fatiga. Su memoria es compartida y vectorizada, no personal. Y cuando falla, la responsabilidad no cae sobre él sino sobre la cadena difusa de decisiones humanas que autorizaron su despliegue.

Esto no invalida los marcos. Los limita. Nos dan vocabulario, estructura y precedente. No nos dan la disciplina específicamente maquínica que este momento pide. Y esa disciplina todavía no está escrita.

La respuesta razonable no es abandonar Scrum ni PMBOK. Es reconocer que son el andamiaje disponible mientras se construye lo que viene. Y ese andamiaje necesita tres cosas que ninguno trae de serie:

  • Cadencia adaptada a las frecuencias reales de cada actor, no a la biología humana.
  • Observabilidad continua que sustituya a la supervisión intermitente.
  • Responsabilidad reconstruible desde la firma individual hacia la trazabilidad estructural.

Preguntas abiertas

  • Si Scrum funciona porque hay un equipo humano que aprende en las retrospectivas, ¿qué queda cuando los actores aprenden en el ciclo del entrenamiento y no en el del sprint?
  • Cuando PMBOK exige responsable identificable para cada decisión, ¿qué le pedimos cuando la decisión emerge de la cooperación de varios agentes sin autor localizable?
  • ¿Sigue siendo un “sprint” cuando el equipo no duerme, o le estamos poniendo nombre humano a otra cosa?

Las preguntas no tienen respuesta cerrada. Pero conviene una idea final: coordinar máquinas no es coordinar humanos más rápido. Es un problema distinto que hemos empezado a abordar con el vocabulario que teníamos a mano — el de la gestión de proyectos clásica. Nos sirve para nombrar lo evidente. Falta el vocabulario para lo específicamente nuevo. Y esa disciplina, cuando se escriba, la sostendrá quien construya los sistemas.

Referencias