Agile no es correr más: es aprender antes

Si trabajas en un equipo de tecnología, es probable que hayas escuchado estas palabras más de una vez. Pero, ¿realmente sabemos qué significa trabajar con Agile o solo estamos siguiendo una receta? En este post repasamos los conceptos que merece la pena entender antes de hablar de herramientas o inteligencia artificial.

Cuando hablamos de Agile aparecen rápidamente palabras como Sprint, Daily, backlog, Scrum Master o Jira. Pero Agile no consiste en llenar el calendario de reuniones ni en mover tarjetas de una columna a otra. Para mí, la idea es mucho más sencilla:

Hacer algo pequeño, comprobar si aporta valor, aprender y decidir el siguiente paso. Y repetir.

Ahora, además, tenemos una herramienta que puede acelerar bastante ese ciclo: la inteligencia artificial. No para sustituir al equipo, sino para reducir tareas mecánicas y permitirnos dedicar más tiempo a pensar, colaborar y tomar decisiones.

Agile no es solo Scrum

Aunque muchas veces utilizamos Agile y Scrum como si fueran lo mismo, no lo son. Agile es una forma de trabajar basada en la colaboración, la entrega frecuente de valor y la capacidad de adaptarnos a los cambios. Scrum es uno de los marcos que podemos utilizar para llevar esas ideas a la práctica, pero no es el único:

Lo importante no es cumplir un framework al milímetro, sino conseguir entregar, recibir feedback y adaptarnos.

¿Cómo se trabaja?

En lugar de intentar definir todo un producto desde el principio, Agile propone avanzar en pequeños pasos: Priorizar → Construir → Validar → Aprender → Adaptar. Si utilizamos Scrum, este ciclo se organiza en Sprints con estos momentos:

• Sprint Planning: decidimos qué queremos conseguir.
• Daily: revisamos cómo avanzamos y si existen bloqueos.
• Sprint Review: enseñamos lo construido y recogemos feedback.
• Retrospectiva: analizamos cómo podemos trabajar mejor.

El problema aparece cuando estas reuniones se convierten en un trámite. Una Daily no debería ser una reunión para contarle a un responsable qué hicimos ayer, y una retrospectiva sirve de poco si encontramos los mismos problemas Sprint tras Sprint y nunca hacemos nada con ellos. Las ceremonias tienen sentido cuando nos ayudan a inspeccionar y adaptar nuestra forma de trabajar.

¿Qué figuras podemos encontrar?

Si hablamos de Scrum, encontramos tres responsabilidades principales:

Pero en un equipo real podemos encontrar muchos más perfiles:

Perfiles orientados al producto: UX/UI Designer — diseña la experiencia. Business Analyst — traduce necesidades en requisitos. QA o Tester — garantiza que lo construido funciona.

Perfiles técnicos: Tech Lead — define la dirección técnica. DevOps — cuida infraestructura y despliegue. Data Engineer — prepara datos y tuberías. AI Engineer — integra modelos de IA.

Otros roles clave: Stakeholders — representan intereses del negocio. Usuarios — la razón de existir del producto. Su feedback es la fuente principal del ciclo Agile.

Un equipo Agile funciona mejor cuando diferentes especialidades trabajan juntas alrededor de un mismo objetivo.

Las herramientas ayudan, pero no hacen Agile

Instalar Jira no convierte automáticamente a una organización en Agile. Las herramientas deberían ayudarnos a que el trabajo y la información sean más visibles:

La herramienta concreta es secundaria. Lo importante es evitar que conocer el estado de un proyecto implique revisar cinco aplicaciones distintas y preguntar a media organización.

Agile + IA

Aquí es donde creo que la cosa empieza a ponerse especialmente interesante. En un equipo Agile existe mucho trabajo alrededor del trabajo: resumir reuniones, actualizar tickets, ordenar feedback, redactar historias, preparar criterios de aceptación, crear casos de prueba, buscar documentación y generar informes. Muchas de estas tareas pueden acelerarse con inteligencia artificial.

Por ejemplo, herramientas como GitHub Copilot o Cursor pueden generar tests de aceptación directamente desde la historia de usuario, mientras que un LLM puede analizar comentarios de usuarios para agrupar problemas comunes. También puede ayudarnos antes de una Planning detectando historias demasiado grandes o requisitos ambiguos, y en una retrospectiva puede agrupar comentarios similares para que el equipo se centre en hablar sobre los problemas.

En desarrollo puede ayudarnos a generar código, pruebas o propuestas de cambios. Si además el equipo trabaja con feature flags o ramas cortas tipo trunk-based, el ciclo de entrega se vuelve aún más corto: menos tiempo entre escribir código y comprobar si funciona en producción.

El ciclo podría pasar de algo como:

Historia → Desarrollo → Pull Request → Review

a:

Historia → IA propone → Equipo revisa → IA ejecuta → Persona valida

La IA acelera algunas partes del proceso.

Pero hay una diferencia importante:

La IA puede ayudarnos a producir. No debería decidir qué merece la pena producir.

El riesgo de ir más rápido

Aquí está probablemente el punto más importante. Si utilizamos IA únicamente para generar más historias, más código, más documentación y más funcionalidades, podemos aumentar muchísimo nuestra capacidad de producción. Pero eso no significa que estemos construyendo mejores productos.

Un indicador habitual es la velocity: cuántas historias completamos por Sprint. Si la IA nos permite entregar el doble, la velocity sube. Pero si esas historias no resuelven problemas reales, estamos acumulando deuda disfrazada de productividad. Podemos tener un Sprint con 40 historias cerradas y ninguna que el usuario haya pedido.

Podemos ir muy rápido…

…en la dirección equivocada.

Y precisamente ahí Agile sigue teniendo todo el sentido.

Si cada vez cuesta menos desarrollar una funcionalidad, la pregunta importante deja de ser:

¿Podemos construirlo?

Y empieza a ser:

¿Merece la pena construirlo?

La IA puede analizar, resumir, proponer y ejecutar.

Pero seguimos necesitando personas que entiendan al usuario, cuestionen ideas, prioricen y tomen decisiones.

Primer paso concreto

Si mañana tienes una Planning o una retrospectiva, prueba algo sencillo: antes de estimar o priorizar, pregúntate con el equipo “¿por qué esta historia y no otra?”. No necesitas instalar nada ni cambiar tu proceso. Solo una pregunta que obliga a conectar el trabajo con el valor real. Si la respuesta no es clara, quizá esa historia no debería estar en el Sprint.

El Agile que viene

No creo que el futuro de Agile consista en inventar más ceremonias. Creo que estará en conseguir que personas, herramientas y agentes compartan mejor el contexto: que la IA pueda preparar información antes de una reunión, que relacione feedback con funcionalidades, que un agente pueda ejecutar tareas bien definidas. Y que las personas podamos concentrarnos más en descubrir qué problema merece realmente nuestra atención.

Porque Agile nunca trató simplemente de trabajar más rápido. Trató de reducir la distancia entre hacer algo y descubrir si estábamos haciendo lo correcto. Y ahí la IA puede convertirse en una gran aliada.

Glosario rápido

Si algún término del post te resulta nuevo: