Asymmetric Agile: ¿Tu equipo tiene una velocidad o tiene velocidades?

Desde hace un tiempo vengo notando algo en mi día a día y también leyendo sobre ello: la IA aceleró el ritmo de desarrollo, pero eso terminó generando una sobrecarga en QA. El resultado natural es que los devs terminan algunas semanas adelantados — no porque algo esté mal, sino porque cada parte del proceso tiene su propio ritmo.

¿Qué hacés en esa situación? Lo que hace cualquier dev: tomás historias de los sprints siguientes para no quedarte parado. Historias que el negocio todavía no priorizó formalmente, que QA todavía no vio, que el PO capaz ni terminó de refinar. Y así el ciclo se repite. Terminás esas también. Tomás más. La bola de nieve crece.

Y lo más curioso de todo: nadie en el equipo lo ve como un problema.

El manager mira el burndown chart y está verde. El PO ve stories entregadas. Los dashboards dicen que todo marcha bien. Desde afuera, el equipo es productivo. Desde adentro, el sistema está roto.

Hay una narrativa instalada de que la inteligencia artificial va a reemplazar desarrolladores. En la práctica, al menos por ahora, está pasando exactamente lo contrario: la IA nos hace más productivos, lo que significa que producimos más, lo que significa más trabajo en el pipeline, más presión sobre QA, más reuniones, más contexto que manejar.

Un estudio publicado hace apenas unos días en Harvard Business Review confirmó lo que muchos ya sentíamos antes de que la academia lo dijera. Investigadores de UC Berkeley pasaron ocho meses adentro de una empresa tech de 200 personas observando qué pasaba cuando los empleados adoptaban IA genuinamente. El resultado: trabajaban más rápido, tomaban más tareas, y extendían el trabajo a horas que antes eran personales — sin que nadie se los pidiera. El artículo se llama "AI Doesn't Reduce Work — It Intensifies It" y la conclusión es clara: la IA está generando más burnout, no menos.

Porque la herramienta acelera solo una parte del proceso. Y esa es exactamente la trampa.

Trabajo con GitHub Copilot y Claude todos los días. Me ayudan a resolver problemas técnicos más rápido — esos que sé exactamente cómo solucionar pero que implementarlos a mano llevaría el doble de tiempo. El deliver se vuelve más veloz. Pero QA no puede cambiar sus tiempos. No porque sea ineficiente, sino porque la validación tiene un piso humano que ninguna herramienta elimina del todo.

El Dev Stream se aceleró, el Validation Stream no, y Scrum no tiene respuesta para esa asimetría.

Scrum fue diseñado en un mundo donde dev y QA tenían velocidades más o menos comparables. El sprint como unidad de tiempo tenía sentido porque todos los engranajes giraban a una velocidad similar.

Hoy eso no es así. Y no es culpa de Scrum — es que el contexto cambió y la metodología no evolucionó todavía.

El síntoma más claro está en la estimación. En Scrum, una historia tiene un tamaño: X story points. Pero ¿X para quién? Para dev, una historia puede ser 3 puntos. Para QA, la misma historia son 8. Integration tests, casos edge, regresiones, flujos de usuario completos — la validación tiene su propia complejidad que no está capturada en ningún lugar del proceso actual.

La estimación actual es una mentira a medias. Estamos midiendo solo la mitad del trabajo real.

Pero el problema más profundo no es la estimación — es lo que pasa después. Dev termina, marca la historia como done, y la "tira por la pared" a QA. QA la agarra desde cero, sin contexto, y empieza a validar todo desde el principio. No porque desconfíe del dev en particular, sino porque el proceso no le da ningún contrato formal en el que apoyarse.

Eso es lo que Asymmetric Agile viene a cambiar.

No se trata de tirar Scrum. Se trata de reconocer que el equipo ya no tiene una velocidad — tiene velocidades — y diseñar el proceso alrededor de esa realidad.

Los pilares son cuatro:

Lo que se mantiene igual: épicas, refinamiento, retrospectivas, t-shirt sizing como base. No es reinventar la rueda, es agregar las dimensiones que faltan.

Imaginemos que estamos construyendo una bicicleta y la historia del sprint es: como ciclista, quiero tener luces delanteras y traseras para poder circular de noche.

En Scrum clásico, dev instala las luces en dos días y la pasa a QA, que tiene que validar: iluminación suficiente, visibilidad trasera, resistencia a la lluvia, batería baja, interferencia con el freno, compatibilidad con el dinamo. Lo que para dev fueron 2 días, para QA son 8. El sprint termina y QA todavía está en las luces.

En Asymmetric Agile:

Esa decisión — C2 para la demo, C3 para el release — es explícita y consciente, no un workaround informal de último momento.

Si el buffer se llena, dev no toma más historias: invierte ese tiempo en mejorar la cobertura de C1, reduciendo la carga de QA en lugar de agrandar el cuello.

La IA adoptada solo en el Dev Stream no es una ventaja — es un desequilibrio. Asymmetric Agile no resuelve ese desequilibrio aumentando la velocidad de QA, sino redistribuyendo formalmente la responsabilidad de validación entre los dos streams.

La velocidad del equipo deja de ser un número engañoso. El cuello de botella se vuelve visible antes de que explote. Dev no puede tirar una story por la pared a QA — eso cambia la conversación de "¿por qué tardás tanto?" a "¿qué necesitás de mi parte para que C1 sea confiable?"

El resultado no es un equipo más rápido. Es un equipo que sabe exactamente dónde está parado en cada momento, que toma decisiones conscientes sobre qué nivel de confianza necesita cada feature, y que no necesita tres sprints de buffer para descubrir que algo está roto.

Si trabajás en un equipo donde dev siempre está adelante de QA, donde la estimación no refleja el trabajo real, y donde los dashboards dicen que todo está bien mientras el equipo se agota: esto es para vos.

No hace falta reescribir todo el proceso de un día para el otro. Tres pasos concretos para empezar en el próximo sprint:

Esos tres pasos no son Asymmetric Agile completo. Son suficientes para empezar a ver la asimetría con claridad.