Agility Might Have Been Waiting for AI

Originally published on yuvalyeret.com.AI is forcing everybody to be very agile about who they are, what they do, what impact can they make, and how they're perceived, including myself. I've pivoted from Scaling with Agility to Scaling AI from Activity to Impact.

Originally published on yuvalyeret.com.AI is forcing everybody to be very agile about who they are, what they do, what impact can they make, and how they're perceived, including myself. I've pivoted from Scaling with Agility to Scaling AI from Activity to Impact.

Am I just jumping on the AI bandwagon?I've worked on AI-adjacent scaling and agility challenges quite a bit over the last couple of years and that's shifting into AI adoption in product/engineering organizations and the wider business more recently. I've noticed that there's a lot in common.

Many of the patterns that I developed, used, and avoided for improving development lifecycles and how companies work over the years are very applicable when trying to shift organizations from AI ambition to AI-Native operating systems. For example, AI theater caught up very quickly to something that took a decade in the agile world to happen. AI is much faster about everything.

All the way from network / operating-system plumbing to AI-Native plumbingI often say that I'm a plumber. Not because that's maybe the profitable future for us knowledge workers when AGI is here, but no. I found myself over the years, whether it was in the Israeli Air Force back in the nineties, or leading engineering teams and building engineering systems, or over the last almost twenty years at this point helping leaders improve flow in their engineering pipelines and eventually outside of engineering in marketing, sales, throughout the organization. It's like plumbing. Sometimes things are stuck, sometimes there's a bottleneck, sometimes there's a very ugly mess on the floor that you need to clean up. Whatever the context, I come and help organizations, and I do that much better than I do real plumbing.

In context

• Topic: Proyectos, PMO y Riesgos — Gestión de proyectos, oficinas de proyecto y riesgo del portafolio.
• Source: Scrum.org
• Published: 27/08/2026

Continue reading at the original source →

Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.

Por qué importa

En gestión de proyectos casi todo lo que se discute como problema técnico es en realidad un problema de expectativas mal negociadas al principio. Alcance, plazo y costo se pactaron en un momento en que nadie tenía la información suficiente, y después nadie quiso reabrir la conversación.

Leo estas cosas buscando dónde estaba el riesgo antes de convertirse en incidente. Casi siempre ya estaba escrito en algún registro que nadie revisaba, con un dueño asignado que nunca se enteró de que lo era. El riesgo identificado y no gestionado es peor que el no identificado: da la falsa sensación de que hay control.

Lo que suele salir mal

El error clásico es tratar la gestión de riesgos como un entregable de la fase de planificación. Se arma la matriz, se aprueba, se archiva. Nadie la vuelve a abrir hasta el cierre, cuando sirve para documentar que el riesgo estaba previsto — que es exactamente lo contrario de gestionarlo.

Qué mirar

• El tamaño de la primera entrega útil: mientras más lejos esté, más se parece a una apuesta.
• Cómo se estimó y qué tan cerca estuvieron las estimaciones anteriores de la misma organización.
• Quién es el patrocinador y con qué frecuencia real aparece — no en el organigrama, en la agenda.

Cómo leo esta entrada

Yo lo usaría para revisar cómo se estima en la organización. Si las estimaciones históricas se pasaron sistemáticamente por la mitad y nadie ajustó el método, no hay proyecto que salga bien: se está planificando con un metro que mide corto y culpando al equipo por no llegar.

La noticia original está publicada en otro idioma; acá se cita el extracto tal como lo entrega el medio y el comentario se escribe en español.