Versión ampliada en el blog: Agile en la práctica: cada día es un sprint
Buenas! En la newsletter te vas a encontrar:
Un articulo de “mi jefe”, sobre la evolución de la gestión de proyectos
Un evento para aplicar mindset de producto en la búsqueda de trabajo (+350 personas apuntadas)
Os presento a Abel Yécora, Líder de Producto en Ardia
Abel es de esos perfiles que cuesta encasillar. Y eso es precisamente lo que le hace interesante. Lleva más de veinte años moviéndose entre proyectos, tecnología e innovación, siempre con la misma idea en la cabeza: hacer que las cosas funcionen mejor.
Es experto en automatización y metodologías ágiles, pero lo suyo no va solo de herramientas; va de entender a las personas, los equipos y cómo conectar todo para que avance. Como CPO en Ardia , impulsa productos con una mirada muy clara: aportar valor sin complicar la vida a nadie.
Abel tiene una mezcla curiosa. Sabe de gestión, sabe de tecnología y sabe contarlo. De ahí que sea instructor en LinkedIn Learning y que lleve años con Proyecta, su podcast sobre proyectos, productividad y formas más humanas de trabajar.
Quien trabaja con él suele decir lo mismo: es claro, es directo y baja lo complejo sin hacer ruido. No vende humo, no complica lo simple y siempre busca el famoso punto medio entre visión y realidad.
En 2025, Abel destaca por algo que no aparece en los títulos ni en los certificados: criterio, calma y una forma de liderar que hace que la gente quiera trabajar con él. Su misión es sencilla: usar la tecnología para mejorar la vida de las personas, no para llenarla de más procesos.
Os dejo su articulo
Porque lo llaman “Agile”, cuando quieren decir “!@#$%^&”
Hay un momento en la carrera de cualquier Product Manager, Product Owner o Product Engineer en el que uno deja de luchar contra las metodologías y empieza a observar el contexto con calma. Ese momento suele llegar después de muchas reuniones, muchas prisas, muchos sprints que nunca fueron sprints, y muchas decisiones que nunca pasaron por ningún backlog. En mi caso, llegó trabajando en mis dos últimos productos, donde no solo llevaba el sombrero de Product Owner, sino también el de Scrum Master y Product Engineer. Y, entre todos esos roles mezclados, como si fueran capas que me ponía y me quitaba cada hora, descubrí algo que cambió por completo mi forma de trabajar: no existe el Agile puro. Y está bien que así sea.
La industria tiende a contarte que las metodologías ágiles son el camino, que cada empresa las “implanta” y que todos seguimos los mismos rituales. Daily, sprint planning, refinement, demo, retrospectiva. Todo muy armónico sobre el papel. Pero luego llegas al terreno y te encuentras con empresas donde el patrocinador pide nuevas funcionalidades para dentro de media hora, donde un sprint de dos semanas ya parece eterno, y donde la prioridad cambia más rápido de lo que cualquiera podría predecir. En ese terreno real, el manifiesto Agile se respeta… hasta que deja de respetarse. Y los procesos en cascada que tanto tiempo llevamos superando vuelven, no como un fracaso, sino como una respuesta natural al ritmo que hoy exige el mercado.
Lo que quiero compartir aquí no es una crítica, ni una queja, ni una celebración. Es simplemente una historia de comprensión. El camino por el que entendí que luchar contra la cultura real de una empresa —sus ritmos, sus urgencias, sus miedos— es improductivo. Y que cuando asumimos esa realidad, nuestro trabajo mejora. Porque dejamos de intentar encajar metodologías académicas en organizaciones que viven en un torbellino constante, y empezamos a diseñar productos que sí encajan en esa realidad.
La teoría dice Agile. La práctica dice “lo necesito para hoy”.
Cuando me enfrento a un nuevo producto, normalmente siento la misma ilusión de siempre: entender al usuario, analizar las necesidades, diseñar una solución elegante, preparar un roadmap estructurado y convertirlo en un backlog ordenado, priorizado y justificado. Es decir: hacer las cosas como deberían hacerse.
Pero en mis dos últimos productos, lo que en teoría debía ser un proceso ordenado, en la práctica se convirtió en una carrera continua. Reuniones con dirección que acababan con un “¿Y esto lo podemos tener mañana?”; demos que se adelantaban porque “es que hoy viene una persona importante y queremos enseñarle algo”; entregas que pasaban de semanas a horas; decisiones que se tomaban sin verificación técnica porque “da igual que no funcione, con que lo parezca llega para esta presentación”.
Ese “que lo parezca” es el mantra no oficial de muchas empresas. Y no nace de la maldad ni de la ignorancia, sino de la necesidad. Cuando la competencia avanza rápido o cuando simplemente el miedo a quedarse atrás pesa más que la planificación, los ciclos se comprimen y el objetivo deja de ser “hacerlo bien” para convertirse en “mostrar algo ya”. Y entonces de Agile no queda más que la palabra.
Y eso nos deja en una situación incómoda: queremos hacer Agile, pero la empresa trabaja en modo Cascade Express. Queremos aplicar un DoD sólido, pero nos piden entregar sin pruebas. Queremos construir producto con calidad, pero nos piden prototipos que parecen features y features que en realidad son prototipos.
¿Es frustrante? Sí.
¿Significa que la empresa trabaja mal? No necesariamente.
¿Significa que Agile ya no sirve? Tampoco.
Significa que Agile, tal como está escrito, no se diseñó para un mundo donde la IA obliga a entregar en horas. Donde las oportunidades aparecen y desaparecen en cuestión de días. Donde una presentación inesperada redefine toda la semana. Donde los patrocinadores viven en el ritmo del ahora, no del sprint.
Scrum funciona… hasta que la realidad decide que no funciona
Podemos repetir tantas veces como queramos que Scrum requiere sprints de 2 o 3 semanas, con entregables probados, refinados y validados. Podemos defender que sin Definition of Done no hay producto, que sin backlog grooming no hay claridad y que sin retro no hay aprendizaje.
Pero cuando se trabaja en empresas donde la necesidad es hoy, no dentro de 21 días, los sprints dejan de tener sentido. Pasan a ser un decorado, un marco mental que utilizamos para sentir que seguimos una metodología cuando en realidad lo que hacemos es apagar fuegos a alta velocidad.
La dirección quiere entregas constantes, y quiere ver progreso visible, aunque no esté terminado, y el equipo se adapta, porque no adaptarse significa bloquear la empresa. Un Product Manager que no entiende eso… se convierte en un freno.
En esos entornos, Scrum no muere. Se transforma.
Cada día es un sprint.
Cada entregable es una demo.
Cada cambio es un backlog improvisado.
Cada urgencia es una user story recién nacida sin aceptación formal.
Al principio, intenté luchar contra esto, explicar los riesgos, advertir de la deuda técnica, recordar la importancia de la calidad, pero con el tiempo entendí que luchar contra el contexto es una batalla perdida e innecesaria, porque cuando entiendes que ese ritmo responde a una cultura propia, aprendes a trabajar con ella, no contra ella.
La revelación: no se trata de metodologías, sino de expectativas
El verdadero problema nunca fue Agile. Ni Cascade. Ni Scrum. Ni Kanban. Ni las ceremonias. Ni los roles. El problema siempre fue la gestión de expectativas.
Cuando los patrocinadores creen que Agile significa “rápido”, se frustra todo el mundo. Cuando los equipos creen que Agile significa “calidad incremental con control”, se frustra todo el mundo. Cuando nadie alinea qué significa “hecho”, “urgente” o “prioritario”, se frustra todo el mundo.
Yo lo he aprendido a base de golpes, que el trabajo de un Product Manager no es imponer una metodología, sino traducir expectativas. De arriba hacia abajo y de abajo hacia arriba.
Traducir la urgencia del CEO en un entregable viable.
Traducir la complejidad técnica en decisiones de negocio entendibles.
Traducir un roadmap rígido en una guía flexible.
Traducir una idea poco madura en un prototipo funcional.
Traducir la visión en algo tangible sin exigir al equipo milagros imposibles.
Cuando comprendí esto dejé de pelear y empecé a construir con una claridad distinta. Ya no estaba tratando de encajar procesos ideales en un ecosistema que nunca sería ideal, sino construyendo productos que sí se adaptaban al ecosistema real.
Agile es perfecto para lo que no sabemos. Cascade es perfecto para lo que sí sabemos.
Esta frase, que repito mentalmente más veces de las que creo, se convirtió en una brújula.
Agile es ideal cuando no sabemos exactamente qué queremos construir.
Cascade es ideal cuando sí lo sabemos.
El problema es que muchas empresas dicen saber lo que quieren, pero en realidad están descubriéndolo mientras avanzan. Y eso genera una fricción constante: quieren la flexibilidad de Agile, pero con las garantías de Cascade. Quieren velocidad, calidad, investigación, entrega inmediata, validación técnica y presentación impecable… todo a la vez.
Esa tensión solo tiene una salida posible: adaptación continua.
Por eso, aunque nos cueste admitirlo, en la práctica trabajamos en una mezcla que no aparece en ningún manual. Un híbrido que cambia según el día, el contexto, el ánimo del director, el cliente que visita, la oportunidad que surge o la urgencia que aparece.
Es Agile cuando necesitamos explorar. Es Cascade cuando necesitamos mostrar algo rápido. Es improvisación cuando necesitamos sobrevivir.
Y lo más sorprendente es que todo esto funciona… cuando dejamos de sentir que debería funcionar de otra manera.
Los desarrolladores como piedra angular: darles el contexto para brillar
En este tipo de entornos, el equipo de desarrollo suele ser quien más sufre los cambios constantes. Lo que hoy es urgente mañana puede no serlo. Lo que hoy parecía una funcionalidad clave mañana se convierte en un prototipo descartado. Lo que hoy estaba en el backlog mañana desaparece porque ha surgido algo más importante.
Mi aprendizaje clave aquí fue simple, no puedo luchar contra las personas, pero sí puedo darles claridad y propósito.
Los desarrolladores no necesitan que todo sea perfecto. Necesitan saber por qué hacen lo que hacen, necesitan entender el contexto para priorizar bien, necesitan un Product Manager que traduzca ruido en decisiones. Y un patrocinador que entienda que calidad, velocidad y estabilidad nunca son simultáneas.
El día que dejé de intentar cambiar la cultura de la empresa y empecé a empoderar al equipo; explicándoles la realidad, anticipando urgencias, dando visibilidad, negociando tiempos, protegiendo cuando era necesario, la dinámica cambió. Dejó de haber resistencia, dejó de haber frustración, y empezó a haber foco. Porque cuando el equipo entiende el porqué, la metodología se vuelve irrelevante.
La llegada de la IA: el golpe final al Agile clásico
Durante años vivimos un mundo donde el desarrollo era lento y predecible. Proyectos que duraban meses o incluso años. Roadmaps con fechas razonables. Requerimientos más o menos estables.
Agile llegó para adaptarse a este mundo en transformación constante, donde los cambios podían aparecer cada pocas semanas.
Pero hoy… hoy entregamos en horas.
La IA lo ha cambiado todo. Ya no compites contra empresas, compites contra la velocidad del propio mercado. Una idea que ayer era diferencial hoy es un estándar. Un prototipo que hoy parece funcional mañana está obsoleto.
Y las metodologías… no han tenido tiempo de actualizarse. Por eso, en el día a día, vivimos un modo de trabajo que es más cascade reactivo que Agile iterativo. Una cadena donde:
El patrocinador pide algo inmediatamente.
El Product Engineer diseña una solución rápida.
El equipo de desarrollo deja todo para implementarla.
Y mañana quizá no haga falta, pero hoy sí.
¿Rompe esto cualquier proceso tradicional? Claro que sí. ¿Significa que está mal? No necesariamente. Esto solo significa que la metodología no puede ser el centro. El contexto sí.
La reflexión final: cuando entiendes el contexto, tu trabajo se vuelve más claro
Después de todo lo vivido con mis dos últimos productos, llegué a una conclusión que me cambió la forma de trabajar. No se trata de Agile. No se trata de Cascade. No se trata de Scrum, se trata de entender lo que los interesados realmente necesitan y trabajar desde ahí.
Cuando dejas de luchar contra el proceso ideal y empiezas a trabajar con el proceso real, tu rol cambia:
Dejas de frustrarte por lo que debería ser.
Empiezas a diseñar desde lo que es.
Alineas expectativas en lugar de imponer metodologías.
Construyes producto que funciona para tu contexto, no para el manual.
Y aceptas que la perfección metodológica no existe. Lo que sí existe es el valor.
Y cuando entiendes esto, algo curioso ocurre. Tu trabajo fluye mejor, el equipo respira mejor y la dirección empieza a ver que entregas, no porque sigas Scrum con precisión quirúrgica, sino porque eres capaz de convertir caos en progreso y expectativas en realidad.
Ese, al final, es el verdadero trabajo de un Product Manager en el mundo actual, ser el traductor de expectativas de interesados a los desarrolladores, y saber moverse entre ambos sin perder el sentido del producto.
👉 Ofertas que gestiono: empleo.beproduct.es/jobs
👉 Todas las ofertas de producto: beproduct.es/ofertas-producto
👉 Salarios de producto 2026: beproduct.es/informe-salarios
👉 Únete a la comunidad: beproduct.es/unete-comunidad-producto
👉 Sigue leyendo en el blog: Reuniones o comunicación asíncrona · Síndrome del objeto brillante en el roadmap
Creo que aquí hay un matiz importante que suele generar confusión: Agile y Scrum no son lo mismo. De hecho, el propio Manifiesto Ágil deja claro que:
- “Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo…”
- “Entregamos software funcional frecuentemente… con preferencia al periodo de tiempo más corto posible.”
Las claves están justo ahí: aceptar el cambio y entregar en ciclos cortos, no necesariamente sprints de dos semanas (que muchos equipos tienen escrito en piedra). Eso es Scrum, o mejor dicho, una forma de llevar los principios ágiles a la práctica.
Creo que mezclar ambos conceptos puede llevar a conclusiones equivocadas. Agile es el marco de principios; Scrum es solo una de las maneras (ni la mejor ni la peor) de aplicarlos que no siempre facilita esa "agilidad".