¿Agilidad o humo? La realidad que no encaja en empresas ágiles

¿Agilidad o humo? Reflexión sobre los servicios y la realidad que no encaja en las empresas “ágiles”

Esta entrada es una reflexión —con cariño, pero también con un poco de autocrítica— sobre el humo que se genera cuando la agilidad se vende como servicio o como manera de hacer las cosas, y sobre esa realidad empresarial que no encaja con el manual, que no se adapta, que no se doblega.

La verdad es que la reflexión viene de la realidad que veo, que leo, que escucho y que analizo

El día que la agilidad se convirtió en un producto. Spoiler –> HUMO

Voy a ser honesto: me gusta la agilidad. Me gusta el espíritu original. Ese “deja de escribir biblias, entrega algo, aprende, repite”. Eso es sensato. El problema aparece cuando esa idea (que era una reacción práctica a proyectos eternos) se empaqueta, se marca con un logo, se convierte en “framework oficial” y se vende como si fuera un antivirus: lo instalas y ya estás protegido.

Y aquí es donde empieza el humo. Porque vender “agilidad” como servicio o implantarlo por convicción suele degenerar en vender/implantar rituales y roles (Scrum Master por aquí, Agile Coach por allá), más que en vender capacidad (ingeniería, delivery, calidad, aprendizaje).

Es mucho más fácil facturar una implantación de ceremonias que meterse en el barro de tu legacy, tus dependencias, tu modelo de compras y tu cultura de “no toques eso que lo rompe”.

Además, hay una trampa psicológica preciosa: cuando pagas por algo, quieres ver “cosas” pasar. Y las ceremonias son “cosas”: reuniones, tableros, plantillas, formaciones, certificaciones. Entregar valor real es más incómodo, más lento al principio y, sobre todo, deja huella: se nota en producción, en soporte, en clientes. Y eso da miedo.

Así que el mercado hace lo que el mercado hace: optimiza para lo vendible. Y lo vendible no siempre coincide con lo que funciona.

Spoiler: va a doler.

La empresa real: dependencias, legacy, compras, auditorías… y gente

Todos dicen que es fácil. Mienten. O más o menos… porque “ser ágil” en una startup de 12 personas con un producto único y decisión rápida no se parece en nada a intentar mover un banco, una aseguradora o una administración pública donde:

• Hay presupuestos anuales y el dinero se asigna por proyectos, no por productos.
• Las dependencias entre equipos parecen una telaraña.
• Existe legacy (de verdad): cajas negras, integraciones SOAP, batch nocturnos (que nadie sabe que son, y lo peor, ni qué hacen), gente que se jubila y se lleva el conocimiento en una libreta.
• Compras y legal te piden un pliego con alcance cerrado (y tú querías “iterar”).
• La seguridad, compliance y auditoría no son un “stakeholder”; son un muro con puertas (y si no tienes llaves, te estampas).

Y luego está lo más difícil: la gente. El cansancio. El cinismo acumulado de haber vivido tres “transformaciones” con nombres distintos. El “esto ya lo intentamos en 2018 (además suelen acabar con la frase «y no salió»). El “sí, sí, ahora somos ágiles, pero el comité de dirección decide igual”.

La agilidad no fracasa porque Scrum sea malo (he de decir que no me gustan nada los nombres). Fracasa porque la empresa real tiene restricciones (técnicas, legales, económicas y humanas) que no desaparecen por poner un tablero en Jira, planner o en la pared.

Teatro ágil: señales de que estás pagando por rituales, no por resultados

¿Cómo se detecta el teatro ágil? Fácil: cuando todo suena bien… pero nada mejora. Te dejo señales que he visto (y que me huelo que tú también, y si no, observa mejor amigo mío):

• Ceremonias impecables y entregas mediocres. Dailies de 15 minutos cronometrados, pero releases cada 2 meses con sudores fríos, ( o incluso ni eso).
• Velocity como KPI de management. Si la velocidad sube “porque sí”, alguien está jugando al Excel.
• Backlog infinito y prioridades que cambian por Teams. Si el PO no puede decir “no”, el backlog es una lista de deseos, no una herramienta.
• Roles inflados: más gente “facilitando” que construyendo. Ojo, que facilitar mola; pero si hay 1 engineer por cada 2 coaches… algo raro pasa.
• Retros que no cambian nada. Mucho “qué podríamos mejorar” y cero decisiones que sobrevivan a la semana siguiente.
• Definition of Done tipo poema: bonita, larga… y nadie la cumple cuando hay prisa (o sea, siempre).

El síntoma más claro es este: la agilidad se convierte en una capa encima de lo de siempre. Sigues teniendo los mismos aprobadores, los mismos handoffs, los mismos silos… pero ahora además tienes dailies. Maravilloso y desolador.

Agilidad sin ingeniería es como DevSecOps sin ‘Sec’: marketing

Aquí es donde muchos discursos “agile” se caen: hablan de cultura, de mindset, de “empoderar equipos”… y luego miras la parte de ingeniería y ves:

• Tests inexistentes.
• Deploy manual con miedo.
• Entornos que no se parecen entre sí (dev, pre, pro… cada uno con su fauna).
• Observabilidad pobre: logs sin contexto, métricas sin sentido (pero sin ningun sentido).
• Seguridad como ticket al final: “pasad un pentest antes de salir”.

La agilidad operativa se apoya en ingeniería. Punto. Si no puedes integrar cambios frecuentemente, si no puedes desplegar con seguridad, si no puedes detectar fallos rápido, entonces tu “iteración” es teatro. No es que seas mala persona; es que el sistema no te deja.

Y aquí entra arquitectura, que es la palabra que a veces se pronuncia como si fuera pecado. Modularidad, límites claros, propietarios, contratos entre servicios, datos bien gobernados. Si te interesa el tema, tengo un post sobre arquitectura de microservicios donde también pincho burbujas (porque microservicios sin disciplina son una fiesta… pero de las que acaban con la policía).

Vale, pero… ¿qué tiene que ver Iberasync, la ciberseguridad con esto?

Todo. Porque la seguridad es el detector de mentiras más eficiente que existe. Si tu empresa presume de velocidad, pero no puede responder a un incidente, o no sabe qué versiones tiene en producción, o no puede trazar quién aprobó qué cambio… entonces no es agilidad, es temeridad con buena dicción.

Un ejemplo práctico: si no tienes pipeline decente, acabarás haciendo “fast track” de cambios urgentes. Y el fast track es el primo simpático de la chapuza. ¿Resultado? Vulnerabilidades que se cuelan, secretos en repos, dependencias sin parchear. Ya era hora de decirlo en voz alta.

// Un pipeline “ágil” de mentira: rápido para romper, lento para arreglar
// (perdón por el tecnicismo)
stages:
  - build
  - test
  - deploy
build:
  script:
    - echo "Compilando..."  # TODO: compilar de verdad algún día
test:
  script:
    - echo "Tests: 0 ejecutados"  # el clásico
deploy:
  script:
    - echo "Desplegando a producción con fe"  # lo que puede salir mal...

Una forma más honesta de medir: outcomes, no postureo

Si tienes que quedarte con una idea, que sea esta: mide lo que cambia la realidad, no lo que suena bien en una diapositiva.

Story points, velocity, número de historias cerradas… todo eso puede ser útil para el equipo, en privado, como herramienta de planificación. En cuanto lo conviertes en objetivo corporativo, lo conviertes en un juego. Y cuando gamificas métricas, la gente optimiza para la métrica, no para el sistema.

¿Alternativas menos tramposas? Algunas (con matices):

• Lead time real: desde que alguien pide algo hasta que está en producción y aporta valor.
• Deployment frequency y change failure rate (hola, DORA). Ojo: no para competir entre equipos, sino para ver tendencias.
• MTTR: cuánto tardas en recuperar servicio cuando algo peta (Hooo, amigo mío, y petará, te lo aseguro).
• Calidad escapada: bugs que llegan a producción, incidentes, regresiones.

Y luego está la métrica que nadie quiere mirar: coste del retraso. Porque el gran drama de muchas empresas no es que entreguen lento, es que entregan tarde lo importante y rápido lo irrelevante. Eso no lo arregla un daily. Lo arregla priorización con dientes.

A mitad de camino: el punto donde suele romperse todo

Hay un momento típico en estas historias: llevas meses “implantando algo con agilidad”, el entusiasmo inicial baja, la dirección pregunta por resultados, el proveedor enseña un dashboard, y el equipo… está igual o peor. Aquí es donde suelen pasar dos cosas:

• Se dobla la apuesta: más ceremonias, más reporting, más control. (Porque si algo no funciona, la solución corporativa es añadir capas.)
• Se busca un culpable: “los equipos no tienen mindset”, “falta cultura”, “resistencia al cambio”.

Y sí, a veces hay resistencia. Pero muchas veces lo que hay es una arquitectura y un modelo operativo que no soportan iteración rápida. Pretender que la gente “cambie la mentalidad” mientras trabaja con un monolito frágil, sin tests, con deploy manual y dependencias externas que tardan 6 semanas… es cruel. Y un poco absurdo.

La agilidad no es una charla motivacional. Es un sistema.

Qué hacer cuando ya estás dentro del “programa ágil” y huele raro

Vale. Ya estás dentro.. Hay framework. Hay ceremonias. Y tú tienes esa sensación de “esto no encaja”. ¿Qué se puede hacer sin prender fuego a la oficina?

1) Diagnóstico rápido

Yo suelo mirar cuatro cosas, muy terrenales:

• Flujo: ¿dónde se atasca el trabajo? ¿aprobaciones? ¿entornos? ¿dependencias?
• Calidad: ¿cuánto rework hay? ¿cuántos bugs vuelven? ¿cuántos hotfix?
• Operación: ¿cómo se detectan y gestionan incidentes? ¿quién paga el precio?
• Seguridad: ¿se integra o se “pega” al final? ¿hay inventario, parches, secretos?

2) Recortar ceremonia y meter ingeniería

Si el equipo pasa más tiempo en reuniones que construyendo, algo está roto. Reduce. Simplifica. Quédate con lo que aporte. Y con el tiempo liberado, invierte en:

• tests automatizados (unit, integración, e2e donde toque)
• pipeline CI/CD decente
• observabilidad (logs con contexto, métricas)
• refactor y deuda técnica con un plan (no con fe)
• Habla con negocio, prueba con negocio, métete en los pantalones de negocio, be negocio.

3) Poner límites: decir “no” como práctica de supervivencia

La empresa “ágil” que no sabe decir no, no es ágil: es reactiva. Y la reactividad es una forma elegante de vivir apagando fuegos. Define criterios de entrada, WIP limits, y protege al equipo de la avalancha. Esto suena a Kanban básico, pero cuesta mogollón cuando hay política.

Y ahora la frase que molesta: quizá no necesitabas “agilidad”. Quizá necesitabas foco, ingeniería y valentía para priorizar.

Ah, y un detalle: si la transformación no toca cómo se decide el trabajo (presupuesto, prioridades, governance), es cosmética. Bonita, pero cosmética.

Seguridad como prueba de estrés: donde se ve si hay sistema o postureo

En ciberseguridad hay una idea que me encanta porque es brutalmente honesta: no importa lo que digas que tienes, importa lo que resiste un ataque o un fallo. Con la agilidad pasa parecido.

Si quieres saber si tu empresa es “ágil” de verdad, mira:

• Qué pasa cuando hay un incidente serio.
• Si podéis hacer un rollback.
• Si podéis parchear una vulnerabilidad crítica.
• Si sabéis qué está desplegado, dónde, con qué dependencias.

Por cierto: si tu organización se ha subido al carro de “meter LLMs en procesos”, añade otra capa de riesgo (prompt injection, data leakage, supply chain de modelos, etc.). No me enrollo aquí, pero si te apetece el tema tengo un post sobre vulnerabilidades en LLMs. Porque sí, también hay humo ahí, y del bueno.

Lo que sí funciona (cuando funciona): una receta poco sexy

No tengo una bala de plata. Si alguien te la vende, revisa la cartera. Pero sí he visto patrones que funcionan cuando se hacen con honestidad:

• Equipos estables con propietarios reales de un producto o dominio/proceso (no “equipo proyecto” que se disuelve).
• Backlog con dientes: priorización explícita, trade-offs claros,y un PO que puede decir “no”.
• Ingeniería primero: CI/CD, tests, observabilidad, automatización de evidencias.
• Arquitectura pragmática: modularidad, límites, y decisiones registradas (sí, documentar un poco; no pasa nada).
• Seguridad integrada: threat modeling ligero, SAST/DAST donde toque, gestión de secretos, SBOM y parches con cadencia.
• Gobernanza mínima viable: políticas cortas, automatizadas, revisadas. Menos PDF, más controles en pipeline.

¿Suena menos emocionante que “cambio cultural disruptivo”? Sí. ¿Funciona mejor? También.

Y sí, hay una parte que no se puede automatizar: la responsabilidad. La dirección tiene que aceptar que priorizar implica renunciar. Que mejorar fiabilidad implica parar features/mejoras, ir más despacio. Que “ser ágil” no es ir rápido siempre, es poder cambiar de dirección sin reventar.

Si tu organización no puede parar, no es ágil. Está atrapada.

Menos humo, más responsabilidad.

La agilidad no se compra. Se construye. Se sostiene. Y se paga: con foco, con disciplina de ingeniería, con decisiones difíciles y con una cultura que no castigue decir la verdad (“no llegamos”, “esto es frágil”, “esto necesita refactor”, «no necesitamos agilidad, necesitamos más ingenieros»).

El humo de la venta de servicios existe porque hay demanda: queremos soluciones rápidas a problemas complejos. Queremos un framework que nos quite la culpa. Queremos un sello que diga “somos modernos”. Pero el negocio no perdona: los clientes, los incidentes, la deuda técnica y la regulación te acaban poniendo delante el espejo.

Si te llevas algo de aquí, que sea esto: menos ceremonia, más sistema. Menos postureo, más capacidad interna. Menos “agile” como identidad, más entrega real con calidad y seguridad.

Y si alguien te promete “agilidad en 12 semanas”… bueno. Tú ya sabes.