Agile teather: stand-ups, post-its y cero decisiones

Publicado el 12 de agosto de 2026  •  12 minutos  • 2483 palabras

Hay un momento muy concreto en la vida de cualquier dev en el que se da cuenta de que en su empresa no se hace Agile, se hace teatro.

A mí me pasó el día que entré en una sala de reunión, vi una pared llena de post-its de colores, cuatro columnas con nombres en inglés y un cartel enorme de “Somos una organización ágil”, y, al cabo de una hora, me di cuenta de que ni una sola decisión importante se había tomado allí dentro.

Todo se iba a “consultar arriba”.

Ahí entiendes que no estás en un equipo Agile; estás en una especie de escape room corporativo con estética Scrum chupiguay.

La liturgia diaria: 15 minutos de pie para decir que sigues vivo

Para mí Scrum es una religión, aunque ese despiece te lo debo para otro día. Por ahora toca sufrir el ritual, porque las empresas necesitan la pegatina de Agile para vender.

El ritual de la daily es casi siempre igual. Son las 9:15, suena la alarma del “vamos a la daily”, te levantas o te conectas al Teams, haces el peregrinaje hasta la zona sagrada de la pizarra o la pantalla compartida con el tablero.

El Scrum Master (o a veces el Product Owner, o el Project Manager, o incluso el Project Owner, porque ya ni las religiones se respetan) lanza la frase: “Venga, chicos, 15 minutitos, ¿eh?”.

(Odio eso de “chicos”, o “chicas”, me recuerda tanto a mi tiempo en escuelas religiosas …)

Empieza la fiesta:

• “Ayer estuve con el ticket 3245, hoy sigo con el ticket 3245, no tengo bloqueos.”
• “Ayer revisión de PR, hoy más revisión de PR, todo bien.”
• “Ayer estuve en reuniones, hoy también, ya os contaré.”

Vas viendo cómo cada uno recita su parte como si fuera el Padrenuestro, y tú piensas que si un día alguien dijera “no he hecho nada porque no tengo ni idea de qué estamos haciendo”, se produciría un silencio tan incómodo que se abriría un agujero negro en medio del open space.

Lo revelador es lo que no pasa en esa daily. Nadie discute prioridades. Nadie se atreve a decir “esto que estamos haciendo no tiene ningún sentido”. Nadie dice “este ticket está mal planteado, el problema de fondo es otro”.

La daily no está para eso. Está para que la gente de arriba vea que “hay movimiento”.

Atlassian, en un artículo reciente sobre Agile theater , lo definía con bastante precisión: muchas organizaciones convierten las ceremonias ágiles en un espectáculo para tranquilizar a management, no en un mecanismo para tomar mejores decisiones. Y se nota.

Cambiamos los nombres, no las costumbres

Otro día, alguien manda un correo diciendo que la empresa “ha adoptado Agile”.

Lo notas porque, de repente, la gente empieza a cambiar firmas de correo. El project manager, que lleva veinte años gestionando proyectos en cascada, ahora se llama Product Owner. El jefe de equipo ahora firma como Scrum Master. El Gantt se convierte en roadmap. Y las reuniones de seguimiento pasan a llamarse sprint planning, review, retrospective.

Todo nuevo. Todo igual.

En teoría, el Product Owner representa al negocio, prioriza por valor, habla con usuarios, decide qué sí y qué no. En la práctica, sigue recibiendo la lista de “cosas que hay que meter” por parte de dirección, solo que ahora la pasa a tickets de Jira con una columna de “prioridad: alta” para todos.

Lo de decir que no, ni se contempla. Y lo de validar con usuarios reales, ya tal.

Gente con mucha experiencia se ha hartado tanto de esto que ha acuñado términos muy descriptivos: Cargo Cult Agile para hablar de los que copian eventos, artefactos y nombres pero no cambian nada de fondo.

Y es que se ve venir: si lo único que has hecho es rebautizar la jerarquía y pegar post-its, lo que tienes no es agilidad, es cosplay.

Sprints que son cascada con otro filtro de Instagram

Luego llega el momento de planificar sprints. Ahí el teatro alcanza niveles notables.

Se organiza un planning de dos horas, se abre el backlog, el Product Owner empieza a leer user stories como si fuera un lector del BOE, y los devs intentan imaginar qué carajo quieren decir frases tipo “como usuario quiero sentir que me cuidan más” traducidas en tickets de backend.

El sprint se llena de cosas. “Cosas”, no problemas que resolver. Porque casi nunca se plantea “qué queremos aprender en este sprint” o “qué hipótesis vamos a validar”. Lo que se plantea es una lista de funcionalidades que ya vienen dadas: esta, esta y esta, porque “están en el roadmap del trimestre”.

Más de un artículo sobre “Agile gone wrong” lo explica tal cual: muchos equipos no iteran sobre problemas, iteran sobre listas heredadas. Hacen sprints que son simplemente trozos de un plan cerrado hace meses, sin espacio real para corregir el rumbo.

Eso no es Agile, es waterfall cortado en rodajitas. Waterscrum, que lo llaman algunos.

La gracia es que, mientras se trocean las funcionalidades en tickets y se les ponen story points, nadie hace la pregunta importante (incómoda): ¿de dónde ha salido esta lista? ¿Qué evidencia tenemos de que estas cosas importan?

La respuesta suele ser un mix de “lo ha pedido negocio” y “venía en la presentación del Q4”. Es decir: opiniones con PowerPoint.

El arte de pivotar sin mirar un solo dato

Uno de los momentos más surrealistas del Agile teatro es cuando la empresa descubre la palabra pivotar. Es una palabra que queda muy bien en boca de ejecutivos y que da sensación de movimiento inteligente.

“Somos ágiles, pivotamos cuando el mercado cambia.”

En teoría, pivotar significa cambiar de hipótesis cuando la realidad te demuestra que estabas equivocado. En la práctica, en muchas empresas significa “cambiar de idea cada dos semanas porque alguien importante ha tenido una ocurrencia nueva”.

Lo ves así: estás en medio de un trabajo, segunda semana de sprint, bastante enfilado, y de repente aparece un mensaje de “prioridad máxima, hay que reorientar el foco al canal X porque lo ha dicho negocio”.

La historia se repite. La retro dice que esto crea estrés. Se apunta en un post-it. No pasa nada.

Hay artículos enteros dedicados a este fenómeno de “feature factory” donde la organización jamás se para a comprobar si lo que hace sirve para algo. Se pivotan features, se pivotan roadmaps, pero no se pivotan creencias.

Nadie mira una métrica real, nadie revisa hipótesis, nadie admite “esto no funciona”. Lo único que cambia es el color de los post-its.

La retro: qué bien nos desahogamos, qué poco cambiamos

Si quieres medir el nivel de teatro en una empresa, no mires la daily, mira la retrospectiva.

Una retro de verdad es incómoda: salen temas de poder, de prioridades, de cosas que hay que dejar de hacer.

Una retro de teatro es un mural terapia donde todo el mundo se queja con educación y se va a casa con la conciencia tranquila.

He vivido retros donde salían siempre los mismos puntos: demasiadas interrupciones, objetivos cambiantes, falta de claridad en requisitos, managers entrando en la daily a pedir actualizaciones, cero tiempo para pagar deuda técnica.

Se ponían en columnas, se pegaban votos con puntitos, se proponían “acciones de mejora”.

Dos semanas después, misma lista, distinto orden. Hay incluso quien lo ha bautizado como Groundhog Day Agile : el día de la marmota, pero con Miro o Confluence.

El Comité Europeo de la Nada. Se habla, se apunta, se archiva. No se tocan los incentivos, no se cuestiona quién decide qué, no se protege el tiempo del equipo. Pero eso sí, la plantilla de la retro cada vez parece más profesional.

El usuario, ese señor que solo existe en PowerPoint

En casi todo este teatro hay un protagonista ausente: el usuario. No hablo de “la user persona con nombre cuqui” que sale en la ficha de Figma, hablo de personas reales.

Si preguntas cuántos han hablado con un cliente en las últimas dos semanas, el silencio suele ser digno de un velatorio.

Se da por hecho que el Product Owner sabe lo que quiere el usuario. El Product Owner, a su vez, suele saber lo que quiere negocio. Y negocio suele saber lo que quiere el comité ejecutivo.

El usuario real es un eco lejano.

Por eso proliferan artículos con títulos del estilo “Break free from the feature factory” , donde diseñadores y product folks explican cómo se han pasado años sacando cosas sin entender si reducían un dolor real o simplemente llenaban huecos en un roadmap.

Y así es como acabas con productos llenos de funcionalidades que nadie usa, pero que están orgullosamente marcadas como “Done” en tres sprints distintos.

La versión personal: cuando te das cuenta de que estás decorando una obra mala

Si lo bajo al plano personal, el Agile teatro huele así: llegas un lunes, abres Jira, ves tu lista de tickets. La mitad son cosas que sabes que no van a cambiar la vida de nadie. Alguna incluso sabes que va a empeorar el producto (“otro toggle más en un menú que ya da miedo”). Pero están ahí, con su numerito, su descripción y su etiqueta de “commitment”.

Intentas levantar la mano y decir: “Oye, este esfuerzo, ¿por qué no lo invertimos en arreglar esto otro que lleva tiempo dando problemas?”. Te miran con cara de “sí, algún día habrá que hacerlo, pero ahora mismo esto es lo que está en el sprint”.

Lo que está en el sprint adquiere una especie de aura sagrada. No se toca. No se cuestiona. Da igual que el criterio técnico diga lo contrario.

Acabas el sprint con todos los tickets en la columna de Done. Se actualiza la velocidad. Se enseña el gráfico en la review. Se escuchan frases tipo “vamos mejorando” porque la línea de burndown se parece cada vez más a una diagonal perfecta.

Esa noche, si te llevas la conciencia de desarrollador a la cama, igual te cuesta dormir un poco.

Sientes que el código es más frágil, que el sistema es más enrevesado, que os movéis mucho pero avanzáis poco. Y, sin embargo, los números dicen lo contrario. Ahí es donde notas que algo no encaja.

El origen del problema: Agile sin renunciar al mando a distancia

En casi todos los análisis serios sobre por qué falla Agile aparece una idea que no hace mucha gracia en el piso de arriba: Agile exige soltar control. Dar autonomía real a los equipos. Permitir que la gente que está cerca del problema tome decisiones. Aceptar que no se puede predecir todo en un Excel anual .

Esto se ve clarísimo en cuanto pasa algo de verdad.

Piensa en esa retro donde se acaba de acordar, con aplausos incluidos, que “negocio no toca el sprint a mitad de camino”.

Dos días después, el mismo director que asintió en la retro le manda un Slack directo a un dev (saltándose al Product Owner, saltándose el tablero, saltándose todo lo que se firmó hace 48 horas) con un “esto es urgente, para ayer”. El dev mira el mensaje, mira el sprint board, y entiende en tres segundos qué pesa más: lo que se dice en la ceremonia o lo que manda quien firma las nóminas.

Lo que muchas empresas hacen es lo contrario a “soltar cuerda”: añaden las ceremonias encima del modelo de siempre.

Roadmaps cerrados, fechas prometidas a clientes, decisiones estratégicas tomadas por gente que no ha pisado el código ni hablado con un usuario en años. A eso le ponen una capa de Scrum y esperan milagros.

Lo que obtienen es exactamente lo que describen artículos como Agile theater o Agile Gone Wrong : más reuniones, más burocracia, más frustración, y ni rastro de los beneficios que se prometían .

¿Tiene arreglo o solo queda aplaudir desde la butaca?

La parte buena es que no todo está perdido.

He visto sitios donde se ha empezado al revés: no “vamos a hacer Scrum”, sino “vamos a decidir qué queremos mejorar”.

Por ejemplo, he visto equipos donde alguien se plantó y dijo: “Estas dailies no sirven para nada, cambiémoslas o quitémoslas”. Y se atrevieron a experimentar. Menos frecuencia. Más foco en problemas reales. Solo se hace si hay algo que decidir. De repente, la gente dejó de ir en modo zombi.

He visto retros donde se tomó una decisión incómoda, como: “Durante los próximos dos meses vamos a proteger el tiempo de desarrollo y negocio no podrá cambiar prioridades a mitad de sprint sin pasar por aquí”.

Hubo resistencia. Hubo caras largas. Hubo menos “pivots” vistosos. A cambio, el equipo pudo terminar cosas con cara y ojos. Y, sorpresa, las métricas de producto mejoraron.

He visto Product Owners que dijeron no. No a features que no tenían datos detrás. No a peticiones impulsivas. No a “ya que estamos”. Los mismos que luego eran señalados en comités como “difíciles” o “poco flexibles”. Curiosamente, sus productos eran los que tenían usuarios contentos.

Y también he visto lo contrario: sitios donde nada de esto pasa, el teatro sigue, la gente buena se va y la empresa se queda con el decorado y la certificación colgada en la pared.

Si estás en uno de esos equipos donde hay stand-ups, post-its, plannings y retros, pero las decisiones importantes se toman siempre fuera de la sala, no eres tú el raro por sentir que algo huele a cartón piedra. Es que estás en medio de una función de teatro.

La buena noticia es que, una vez ves el telón y los focos, ya no puedes desverlo.

A partir de ahí tienes dos opciones: o intentar cambiar la obra… o irte a buscar un teatro donde, al menos, el guion tenga algo de verdad.

Fuentes y referencias

Para los que llegaron hasta aquí sin irse a la daily de otro equipo, las fuentes detrás de cada argumento:

• Agile Theater - Atlassian Community. Artículo que analiza cómo las organizaciones convierten las ceremonias ágiles en una performance para tranquilizar a management.
• Cargo Cult Agile - dev.to. Ensayo sobre equipos que adoptan la forma de Agile sin entender ni cambiar nada de fondo.
• Cargo Cult Agile - Skeptical Agile. Análisis crítico del culto a la forma sin modificar los procesos reales de decisión.
• Agile Gone Wrong: Scrum y las reuniones interminables - Pasquale Pillitteri. Ejemplos concretos de implementaciones de Scrum que derivan en reunionitis.
• Agile implementation fails: common problems and solutions - The Cranky PM. Análisis de los fallos más habituales en implementaciones de Agile, incluido el patrón Groundhog Day.
• 6 Feature Factory Anti-Patterns - Shane Drumm. Patrones que convierten un equipo de producto en una fábrica de funcionalidades sin valor real.
• Break free from the feature factory - UX Design / Uxdesign.cc. Perspectiva desde diseño y producto sobre cómo salir del ciclo de features sin impacto.
• Autonomía y agilidad organizacional - YouTube. Charla sobre los fundamentos de la agilidad real y la necesidad de soltar el control jerárquico.