Mi daily dejó de ser una reunión
31 AGO 2026
Los agentes ya podían programar, probar y revisar. Lo que faltaba era organización. Cuando roles, handoffs, evidencia y blockers empezaron a persistir fuera de las sesiones, mi daily terminó convertida en atender únicamente lo que requería una decisión.
Los agentes ya podían hacer el trabajo.
Podían leer el repositorio, escribir código, ejecutar pruebas, revisar cambios y reconstruir buena parte del contexto necesario para una tarea.
El problema apareció cuando varios intentaron hacerlo al mismo tiempo.
Una sesión descubría una incompatibilidad. Otra cambiaba un contrato. Una tercera seguía trabajando con la versión anterior. Alguna terminaba y dejaba el resultado únicamente en su mensaje final.
No faltaba otra capacidad en el modelo.
Faltaba una organización capaz de responder quién hacía qué, qué decisiones podía tomar cada responsabilidad, dónde debía persistir un hallazgo y cómo podía continuar otra sesión sin depender de una conversación privada.
Eso era precisamente lo que venía intentando construir: roles reconocibles, autoridad acotada, handoffs explícitos, evidencia persistente y memoria institucional fuera de los agentes.
La organización que originó este experimento
Los agentes no necesitan personajes, necesitan una organización
Al construir un sistema de coordinación para agentes encontré una idea más interesante: quizá no necesitamos inventar roles agénticos, sino adaptar organizaciones que ya sabemos cómo hacer funcionar.
Yo tampoco estaba intentando diseñar una daily más eficiente.
No era un Scrum Master buscando otra dinámica para observar al equipo. Era otro dev sentado en una reunión escuchando durante media hora versiones consecutivas de «no tengo blockers, ayer hice esto y mañana continuaré con aquello».
Entiendo por qué esa sincronización existe.
Eso no hace que automáticamente disfrute participar en ella.
Una mañana abrí el estado del proyecto, leí los blockers que habían aparecido mientras los agentes trabajaban y resolví los que requerían una decisión mía.
Cuando terminaba uno, el agente podía continuar.
Después otro.
Y otro.
No hubo una reunión.
No pregunté qué había hecho cada agente ayer. No escuché siete versiones ligeramente distintas de «sigo trabajando en lo mismo».
Atendí las cosas que impedían que el sistema siguiera avanzando y volví a mi propio trabajo.
Y pensé:
Esto se parece bastante más a lo que siempre quise obtener de una daily.
Luego le pedí una daily al sistema
La parte divertida ocurrió después.
Quería tener una imagen general del proyecto, así que le pedí al sistema algo bastante informal:
Dame el estado tipo daily.
Y lo hizo.
Reconstruyó qué trabajo estaba activo, qué había avanzado, qué estaba bloqueado y qué debía ocurrir después.
Lo interesante no era que un modelo pudiera redactar un resumen. Eso ya no sorprende demasiado.
Lo interesante era de dónde salía la información.
No estaba entrevistando agentes. No estaba leyendo el historial privado de cada conversación. No dependía de que una sesión recordara correctamente lo que había hecho otra.
La mayor parte podía reconstruirse desde el estado persistente de la organización: responsabilidades activas, trabajo reclamado, evidencia, handoffs y blockers.
La daily había pasado de ser una conversación para descubrir el estado del proyecto a ser una consulta sobre un estado que ya existía.
Lo que realmente cambió
La capacidad ya existía. La organización cambió el resultado.
- 01Agentes capacesLeer el repo, escribir código, ejecutar tests y revisar cambios.Cinco ejecutores rápidos todavía pueden producir cinco versiones de la realidad.
- 02Organización explícitaRoles, autoridad acotada, handoffs, blockers y evidencia persistente.El estado del trabajo sobrevive a las sesiones que lo ejecutan.
- 03Atención dirigidaLeer trabajo activo, resolver bloqueos, persistir decisiones y dejar continuar.El tiempo humano pasa de narrar estado a resolver incertidumbre.
Entre el primer y el tercer estado no agregué otra capacidad de programación. Cambié el modelo de coordinación.
Ese cambio me hizo reconsiderar qué parte de la ceremonia me molestaba realmente.
La daily era la consecuencia, no el problema
La guía oficial de Scrum define el Daily Scrum como un evento de 15 minutos para inspeccionar el avance hacia el Sprint Goal y adaptar el Sprint Backlog cuando sea necesario. También permite que los Developers elijan su estructura, siempre que se concentre en el objetivo y produzca un plan accionable.
Dicho así, me cuesta estar en desacuerdo.
Claro que quiero saber si el proyecto avanza.
Claro que quiero detectar impedimentos.
Claro que quiero adaptar el trabajo cuando descubrimos algo nuevo.
El problema aparece cuando la única forma de obtener esa información es reunir a todas las personas para reconstruirla verbalmente.
En muchos equipos, la reunión termina funcionando como una sincronización manual de estado: cada persona explica su copia local y alguien intenta reconstruir qué está pasando realmente.
Tiene sentido.
Los humanos no compartimos memoria.
Una persona puede haber descubierto ayer que una integración no funciona, otra puede estar esperando un cambio que nadie le avisó que ya terminó y alguien más puede haber tomado una decisión que nunca llegó al ticket.
La conversación intenta reconciliar esas copias parciales del mundo.
El problema no es la daily.
El problema es que el sistema de trabajo muchas veces no tiene un modelo suficientemente bueno de su propio estado.
Capacidad sin organización solo acelera el problema
Dar a los agentes más capacidad no soluciona esto automáticamente.
En realidad puede hacerlo bastante peor.
Imagina cinco sesiones trabajando en paralelo.
Una descubre una incompatibilidad.
Otra cambia un contrato.
Una tercera necesita ese contrato, pero cargó el repositorio antes del cambio.
Otra termina una tarea y deja el resultado únicamente en su mensaje final.
La última detecta trabajo adicional, decide que «sería útil» hacerlo y amplía silenciosamente el alcance.
Ahora tenemos cinco ejecutores muy rápidos y cinco versiones distintas de la realidad.
El hecho de que sean agentes no crea coordinación.
Solo permite producir descoordinación más rápido.
Por eso, cuando empecé a diseñar herramientas para trabajar con varias sesiones, una de las decisiones más importantes fue sacar la memoria institucional fuera de ellas.
Una sesión puede morir. Otra puede reemplazarla.
El proyecto debería continuar sabiendo:
- qué resultado perseguimos;
- qué trabajo está reclamado;
- quién tiene autoridad sobre él;
- qué evidencia existe;
- qué dependencias cambiaron;
- qué se descubrió fuera del alcance;
- qué está bloqueado;
- qué decisión permitiría continuar.
Si la respuesta a esas preguntas está únicamente en conversaciones, el proyecto no tiene estado.
Tiene recuerdos.
Un blocker es más útil que un reporte de actividad
Esto cambió también la información que me interesa ver por la mañana.
No necesito necesariamente saber todo lo que hicieron los agentes.
Necesito saber dónde hace falta mi atención.
Si un agente tiene contexto suficiente, autoridad dentro de su responsabilidad, tests verdes y ningún conflicto, probablemente lo mejor que puedo hacer es no interrumpirlo.
En cambio, si aparece algo como:
BLOCKED
Motivo:
El contrato aceptado no define qué debe ocurrir
cuando dos políticas tienen la misma prioridad.
Impacto:
No es posible continuar la implementación
sin elegir semántica.
Requiere:
Decisión de arquitectura.
Eso sí quiero verlo.
Hay una diferencia importante entre:
Runtime agent: ayer implementé A y B, hoy continuaré con C.
y:
Hay una ambigüedad en C que impide continuar y estas son las dos decisiones posibles.
El primero es estado.
El segundo requiere atención.
Cuando el trabajo ocurre en paralelo, la atención humana se vuelve un recurso de coordinación.
No quiero gastarla preguntando por trabajo que puede reconstruirse automáticamente.
Quiero gastarla donde todavía existe incertidumbre que el sistema no puede resolver de manera segura.
La atención humana cambió de lugar
El flujo se volvió bastante sencillo: abro el proyecto, consulto el estado y busco blockers. Si hay uno que requiere mi autoridad, tomo la decisión, la registro y desbloqueo el trabajo. Si no lo hay, dejo trabajar al sistema.
Después puedo pedir una vista global cuando realmente la necesito.
Eso no significa que nunca haya conversaciones.
Al contrario.
Hay problemas que necesitan discusión.
Una decisión de producto ambigua puede necesitar varias perspectivas. Un cambio transversal quizá requiera coordinación entre arquitectura y especialistas. Un fallo complejo puede necesitar investigación conjunta.
Pero ahí la conversación ocurre porque existe algo que discutir, no porque llegó una hora determinada del calendario.
Esa diferencia parece pequeña y para mí es enorme.
La reunión era una interfaz
Creo que esta es la idea que más me interesa de todo el experimento.
Muchas ceremonias de desarrollo también son interfaces.
La daily es una interfaz para observar el estado del trabajo.
Una planning es una interfaz para transformar intención en trabajo comprometido.
Una review es una interfaz para inspeccionar lo producido.
Una retrospectiva es una interfaz para convertir experiencia reciente en cambios del proceso.
Durante mucho tiempo la interfaz más barata para muchas de esas operaciones fue una reunión.
Pones a las personas correctas en la misma habitación, compartes información y reconstruyes un estado común.
Es extremadamente flexible.
También tiene un costo bastante obvio: necesita sincronizar tiempo humano.
Cuando el sistema de trabajo empieza a representar mejor sus estados, relaciones y transiciones, algunas de esas interfaces pueden cambiar.
No necesariamente desaparecer.
Cambiar.
La pregunta deja de ser:
¿Cómo automatizamos la daily?
y se vuelve:
¿Por qué necesitábamos reunirnos para obtener esta información?
Esa segunda pregunta produce sistemas bastante diferentes.
No quiero un robot facilitando la misma junta
La solución menos interesante sería recrear exactamente la ceremonia con agentes.
A las 9:00, cada uno podría contar qué hizo ayer y qué hará hoy. Podría incluso ponerles avatares y hacer que esperen su turno.
Habríamos construido una simulación increíblemente eficiente de algo que yo ya quería evitar con humanos.
La ventaja de que el equipo esté compuesto parcialmente por software es que no estamos obligados a conservar interfaces diseñadas alrededor de las limitaciones humanas.
Un agente no necesita esperar hasta mañana para publicar un blocker. Puede registrarlo en el momento exacto en que aparece.
No necesita recordar durante una reunión qué archivos cambió. Git ya lo sabe.
No necesita explicar que sus tests pasaron. Puede adjuntar la evidencia.
No necesita decir que terminó y ahora otra responsabilidad puede comenzar. Puede emitir un handoff estructurado.
Entonces el resumen diario puede generarse cuando alguien lo necesite.
Asíncrono no significa invisible
Hay una trampa aquí.
Eliminar la reunión sin reemplazar la información que transportaba solamente produce caos asíncrono.
Para que esto funcione, el estado tiene que ser más explícito, no menos.
Un trabajo debería tener propietario.
Un blocker debería describir qué impide continuar.
Un handoff debería decir quién entrega, quién recibe y qué condición cambió.
Una aceptación debería conservar evidencia.
Las decisiones importantes deberían llegar a la fuente normativa correspondiente.
El progreso debería poder reconstruirse sin interpretar veinte mensajes de chat.
Paradójicamente, quitar ceremonias puede exigir más disciplina en el modelo de trabajo.
La reunión tolera bastante desorden porque los humanos somos buenos rellenando huecos conversando.
Una consulta solo puede responder correctamente si la información existe.
Por eso no creo que «trabajar asíncronamente» sea simplemente sustituir reuniones por mensajes.
Es mover coordinación desde memoria humana implícita hacia estado explícito.
Y no, esto no es un Daily Scrum
Vale la pena aclararlo.
Si elimino el evento diario, estrictamente no estoy haciendo el Daily Scrum que define Scrum.
Tampoco tengo demasiado interés en ganar una discusión semántica diciendo que sí.
Mi experimento no intenta demostrar que Scrum debería funcionar así ni que todo equipo humano tendría que eliminar sus dailies.
Los agentes tampoco forman mágicamente un Scrum Team porque les dé nombres parecidos a profesiones.
Lo que me interesa es otra cosa.
Separar la función de la interfaz que usamos actualmente para cumplirla.
Scrum quiere transparencia, inspección y adaptación.
Yo también.
Quiere detectar impedimentos y reaccionar rápido.
Perfecto.
La pregunta que aparece con este tipo de organización es cuánto de eso necesita seguir ocurriendo mediante una ceremonia síncrona cuando el trabajo ya genera estado estructurado continuamente.
En un equipo humano tradicional, la respuesta puede seguir siendo «bastante».
En un equipo de agentes probablemente sea «mucho menos».
Y en equipos híbridos sospecho que estará en algún lugar intermedio.
Lo que terminó gustándome de Scrum
Resolver la organización no volvió más capaces a los agentes. Volvió observable y coordinable el trabajo que ya podían hacer.
Hay cierta ironía en todo esto.
Construir agentes me hizo apreciar más algunas ideas de Scrum justo cuando empecé a necesitar menos sus ceremonias.
El objetivo compartido importa.
La transparencia importa.
Inspeccionar frecuentemente importa.
Adaptar el plan cuando aparece nueva información importa.
Hacer visibles los impedimentos importa muchísimo.
Lo que ya no doy por sentado es que esas propiedades tengan que implementarse siempre con las mismas interfaces.
Quizá parte del futuro del trabajo con agentes no consista en enseñarles a asistir a nuestras reuniones.
Consista en hacer que los sistemas donde trabajan representen suficiente información para que algunas reuniones dejen de ser necesarias.
Esa mañana no sustituí una hora de Scrum con una hora hablando con agentes.
Leí blockers.
Tomé las decisiones que realmente necesitaban una persona.
Y dejé que siguieran trabajando.
Después, cuando quise saber cómo iba todo, pregunté.
El proyecto ya tenía la respuesta.
No quiero automatizar la reunión.
Quiero dejar de reunirnos para reconstruir información que el sistema ya debería conocer.