Cuando la agilidad se "quema": las verdades incómodas que Alistair nos regaló

Alistair compartiendo historias. Fotos de Rose Restrepo.

Alistair Cockburn es uno de los 17 firmantes del Manifiesto Ágil. Conocí vagamente su método Crystal Clear, pero muy profundamente su enfoque con los casos de uso, base de mi trabajo durante casi una década y que a la postre me sirvió para publicar mi segundo tomo de Asuntos de la Ingeniería de Software. Es autor de sendos libros, autor de El corazón de la agilidad (Heart of Agile) y en años recientes tuve la oportunidad de colaborar con él en la traducción al español de algunas de sus conferencias alrededor del mundo.

A Alistair le gusta viajar y pisa tierras suramericanas cada vez que puede. Ahora incluso tiene más razones para ello, aunque no me corresponde decirlo. Esta vez, en medio de sus vacaciones, tuvimos la increíble oportunidad de conversar con él en una sesión extraordinaria: "Respondiendo preguntas con historias" con Alistair Cockburn, una iniciativa de las Comunidades Ágiles Colombia y el Corazón de la Agilidad Latinoamérica que lideró nuestra amiga Rose Restrepo.

Alistair no llegó con PowerPoints bonitos ni con frameworks de moda. Llegó con historias crudas y verdades que duelen. Y la primera bomba que soltó fue devastadora: la agilidad como término está "quemada". Pero la expresión clave allí es “como término”. Entraré en detalle de esta y algunas otras cosas que mencionó. Seguramente algunos asuntos quedarán por fuera de este resumen, pero al final, enumeraré las conclusiones que leí esa noche al cierre de la sesión.

La dura realidad de una palabra prostituida

¿Saben qué significa que algo esté "quemado"? Significa que ha sido usado tanto para la autopromoción que perdió su esencia real. Cuántas veces hemos visto consultores, gerentes y "expertos" vendiendo agilidad como si fuera el último iPhone, prometiendo transformaciones mágicas que nunca llegan.

Pero aquí viene lo brutal: Cockburn admite que no han encontrado una palabra mejor. Estamos atrapados con un término degradado porque, irónicamente, sigue siendo la mejor descripción de lo que realmente necesitamos.

La solución que propone es elegantemente simple y dolorosamente práctica: el Corazón de la Agilidad reducido a cuatro palabras que cualquier niño puede entender: "Colabora", "Entrega", "Reflexiona" y "Mejora". No necesitas certificaciones costosas para esto. No necesitas frameworks complejos. Solo necesitas estas cuatro acciones, punto.

Para saber más sobre el Corazón de la agilidad, puedes leer mi artículo en: Mis notas sobre el Corazón de la Agilidad - Gazafatonario IT.

La inteligencia artificial: el nuevo elefante en la sala

Y entonces llegamos al tema que nos tiene a todos despiertos por las noches: la IA. Cockburn no se anda con rodeos: "la IA cambiará todos los roles". Project managers, Scrum Masters, coaches, programadores, testers. Todos. Sin excepción.

Pero aquí está la parte que reafirma lo que ya hemos hablado en distintos foros: no se trata de si la IA nos va a reemplazar. Se trata de cómo van a cambiar las conversaciones dentro de las empresas. Porque ahora tenemos una "tercera persona" en nuestras colaboraciones: el ChatGPT, el asistente IA, la máquina que puede generar código en segundos.

El problema es que esos segundos se convierten en horas o días cuando intentas conectar ese código con la realidad: bases de datos, sistemas legados, integraciones que son más frágiles que una relación de adolescentes. La IA no es magia, es un asistente muy sofisticado que puede "inventar cosas" si no tienes cuidado.

A propósito, no me gustó que haya usado la palabra “persona” para referirse a la IA, pero quizás es asunto de su español no tan perfecto, aunque lo hace muy bien, así que no le reclamé nada en ese sentido.

La métrica que nadie quiere medir (pero debería)

Aquí viene una de las revelaciones más impactantes de toda la sesión. Alistair, que empezó como metodólogo en 1991, nos suelta esta bomba: es imposible medir la productividad de un programador.

¿Por qué? Porque somos demasiado inteligentes para nuestro propio bien. Cualquier métrica que inventes, nosotros encontraremos la manera de "hacer trampa" con ella. ¿Líneas de código? ¿Puntos de historia? ¿Velocidad? Todo es manipulable. Y estoy siendo literal en buena parte de este artículo con los términos y expresiones que él usó, algunas incluso en inglés.

Pero existe UNA métrica que sí importa, una que puede destruir cualquier productividad sin importar qué tan "ágil" seas: las interrupciones por día. Con solo tres interrupciones diarias, tu productividad se va a cero. Y aquí está el problema: nadie quiere medir esto porque significa admitir que nuestras organizaciones están diseñadas para matar la productividad.

Así que te reto, a ti, gerente de proyecto, jefe, Scrum Master, facilitador, coordinador: mide las interrupciones por día a tu equipo y cuéntanos cómo te va. Si el asunto es grave, siempre puedes leer mi artículo illegitimus non-interruptus - Gazafatonario IT.

La fusión de roles: cuando menos es más

Una de las preguntas más prácticas de la sesión fue sobre la fusión de roles: ¿puede una persona ser Product Owner, Product Manager y Project Manager al mismo tiempo? La respuesta de Cockburn fue refrescantemente directa: "No veo ningún problema".

En empresas pequeñas de tres a cinco personas, esta fusión no solo es normal, es necesaria. El purismo de roles separados es un lujo que muchas organizaciones no pueden permitirse. Y honestamente, ¿no es mejor tener una persona que entiende el panorama completo que tres personas que se pasan el día coordinándose?

El Manifiesto Ágil: perfecto pero forzado

Aquí viene otra verdad incómoda: el Manifiesto Ágil fue diseñado para equipos y proyectos, no para grandes empresas. Cuando intentamos forzar sus principios a organizaciones masivas, estamos pidiendo problemas.

Los valores del manifiesto siguen siendo "perfectos, nada cambia", según Cockburn. Pero aplicarlos a una empresa de 10,000 empleados es como usar un bisturí para cortar un árbol: la herramienta es excelente, pero no para ese trabajo.

Micromejoras: la revolución silenciosa

Para las organizaciones tradicionales y estructuradas, Cockburn propone algo que suena aburrido pero es revolucionario: micromejoras continuas y pequeñas. No puedes cambiar una cultura organizacional de golpe, pero puedes mejorar la calidad de una conversación, de una reunión, de una interacción a la vez.

Es menos sexy que una "transformación ágil" completa, pero es infinitamente más real y sostenible. En este sentido, puedes leer mi artículo Microhábitos para macroimpactos: cómo los hábitos atómicos contribuyen a la sostenibilidad de la transformación organizacional – Lucho Salazar e incluso descargar una presentación que hice algún tiempo.

El Project Manager que sobrevive

En este nuevo mundo híbrido, el gerente de proyecto que sobrevive no es el que controla presupuestos o reportes. Es el que se enfoca en tres cosas fundamentales: bloquear interrupciones para el equipo, garantizar la calidad de la comunidad (comunicación, confianza, educación) y publicar el proyecto a los dirigentes.

La función más importante no es la planificación ni el control. Es la calidad de la comunidad dentro del equipo. Porque sin confianza, sin comunicación real, sin educación continua, no hay framework que te salve. Sin confianza no hay comunicación, sin comunicación nunca llegaremos al “Colabora” del Corazón de la Agilidad.

Mi reflexión final

Al final de esta sesión extraordinaria, una verdad emerge con claridad brutal: la agilidad real no está en los frameworks ni en las herramientas de moda. Está en la calidad de nuestras conversaciones, en nuestra capacidad de adaptarnos sin perder la humanidad, y en nuestro coraje para admitir que la mayoría de lo que llamamos "ágil" es solo teatro corporativo.

Y lo que yo derivo de todo esto: la IA cambiará todos los roles, pero si no arreglamos primero la calidad de nuestras conversaciones humanas, solo automatizaremos la mediocridad. Y eso, mis amigos, no es agilidad... es tragedia con mejor tecnología.

¡Gracias, Alistair por una gran conversación!

 

Los asistentes deleitándonos con las historias de Alistair. Foto de Dennis Arias.

Suplemento: Notas de Lucho sobre “Respondiendo preguntas con historias, por Alistair”

Sobre “la agilidad murió”

Más allá de agile no hay algo mejor. “Dime si hay algo mejor”.

Sobre IA

¿Quién firma las decisiones?

La IA cambiará los roles, pero ¿cómo se cambian las conversaciones en la empresa?

La IA hace instantánea la agilidad.

Sobre gestión híbrida de proyectos

¿Qué hace o puede hacer un jefe de proyectos sin burocracia?

·       Bloquear interrupciones al equipo

·       Garantizar la calidad de la comunidad (el equipo y su entorno)

·       Publicar el proyecto a los dirigentes.

Sobre varios roles en una sola persona

Product Owner + Product Manager + Project Manager

¡Es normal!

Sobre el Manifiesto Ágil

Fue un resultado orgánico.

Si una persona más o una persona menos hubiese participado el resultado hubiera sido completamente distinto.

Fue una elección por unanimidad.

Había muchas cuestiones, muchos valores, ¡elegimos cuatro! “Puedo vivir con estos cuatro valores”.

Un ejercicio interesante es lograr eso en tu propio equipo.

El Manifiesto fue elaborado para equipos y proyectos. No para empresas, sobre todo grandes.

Sobre Scrum

El Scrum original es ágil. Scrum es un espejo.

Las personas no quieren verse en el espejo porque ven sus problemas. Scrum no propone soluciones.

Sobre empresas o estructuras liquidas

No es posible ser “líquido” en ciertos entornos.

Ser líquido puede ser un impedimento para la agilidad.

Sobre productividad y métricas

Si no miden interrupciones por día a un programador, no tienen nada.

Porque las interrupciones (dos o tres) pueden bajar considerablemente la productividad.

Sobre otros aspectos

Los gerentes quieren dinero e influencia.

Usaron la agilidad para subir sus bonos.

Con la IA es lo mismo.

Lo que puedes hacer es mejorar la calidad de vida en tu entorno.

Podcast resumen

Aquí puedes escuchar este breve podcast con el resumen de todo lo anterior.

Tu Definición de Terminado no funciona y lo sabes: lo que puedes hacer a partir del paquete de expansión de la guía de Scrum

La guía de Scrum ha sido, desde su concepción, un referente de simplicidad y claridad. Es un documento muy rico en experiencia frase por frase. Ampliamente usado (aunque no estoy seguro si leído con el mismo ímpetu con el que se intenta usar) y también pródigamente malentendido. En este contexto surge el así llamado Paquete de Expansión de la Guía de Scrum, quizás para llenar el vacío que deja la guía al terminar de leerla, el “¿Qué diablos quisieron decir con todo esto?”

Este documento no reemplaza la guía, de hecho, no es una nueva versión de la guía de Scrum, sino que la complementa, actuando como un puente hacia el presente. Todavía es algo pronto para decidir si era necesario algo así o no. Lo que sí es cierto es que la motivación de los autores detrás del documento es auténtica. El mundo ha cambiado mucho en los últimos cinco años y en todos los entornos hay mucha gente, muchos equipos, muchas organizaciones que no han terminado de entender Scrum ni su guía formal.

Pero si tienes interés: léelo cuidadosamente (en español o en inglés o en el idioma de tu preferencia —¡hay una versión en Klingon! —), analiza si cada concepto, práctica o recomendación propuesta te aplica o no, y comienza a adoptar uno a uno, experimentando, midiendo, aprendiendo. Orgánicamente. No cometas el clásico error de “a partir del próximo sprint todos los equipos deben hacer lo que dice aquí”. No. Así será un ejercicio que te hará fracasar en grande.

Y a propósito de “uno a la vez”, empecemos con uno de los que más me interesó. La Definición de Terminado. Sí, es evidente que un sinnúmero de equipos sigue aplicando mal este compromiso. Se quedan en los aspectos de calidad: que el incremento debe cumplir con Seguridad, que Auditoría debe aprobar, que se hagan las pruebas de regresión, que se elabore un acta o minuta firmada por todos los interesados y un largo etcétera. Y de aquello nada.

¿Y aquello qué es? Valor. Impacto. Beneficio. Para el cliente. Para el usuario. Para el negocio. Incluso para el equipo Scrum.

Los autores de este paquete de expansión, entre los que se cuenta el mismísimo Jeff Sutherland, inventor de Scrum, nos traen una propuesta interesante, dos definiciones de terminado: la Definición de Producto Terminado cuya esencia es la Definición de Terminado existente en la guía; y la Definición de Resultado Terminado. Estos nombres en español son una traducción libre tal y como las interpreto. Vamos entonces por partes.

La Definición de Producto Terminado, que también se puede llamar Definición de Entregable Terminado o Definición de Salida Terminada (en la traducción oficial al español de Alex Ballarin se llama Definición de Hecho de Producto) es el compromiso del Incremento:

•       Describe las medidas de calidad que expresan la debida diligencia para el Incremento, asegurando que pueda ser entregado a los Stakeholders.

•       Se enfoca en el qué fue construido y su calidad, asegurando que está listo para ser potencialmente lanzado.

•       Mide los estándares de calidad y las cualidades del Producto (técnicas y de Producto) que el Incremento debe cumplir.

Entre tanto, la Definición de Resultado Terminado, que también podemos llamar la “Definición de Valor Aportado”, puesto que el término "Valor" es el fin último de cualquier producto. Este nombre me gusta además porque deja claro que no estamos midiendo la funcionalidad entregada (“output”), sino el beneficio real que esta aporta. Incluso “Definición de Impacto Logrado” es buen nombre, ya que denota un cambio significativo en el comportamiento del usuario o en las métricas del negocio (por ejemplo, "aumentar la retención", "reducir las llamadas a soporte"), y describe perfectamente la consecuencia de una salida exitosa. Son ideas. En breve, esta Definición de Hecho de Resultado, como se llama en la traducción oficial:

•       Describe las medidas observables (cuantitativas o cualitativas) que demuestran los beneficios realizados o la validación de valor para los Stakeholders.

•       Se enfoca en el porqué del trabajo, es decir, si lo que se entregó generó el impacto deseado y el valor real.

•       Mide el valor realizado y el impacto para los Stakeholders (incluyendo clientes, usuarios, etcétera).

Ejemplos

Con un ejemplo se entiende mejor. Así que veamos este “paquetico” de expansión al paquete de expansión de la guía de Scrum. Imaginemos un producto, una plataforma de comercio electrónico para pequeños negocios. Una Definición de Resultado Terminado puede contener aspectos como:

Para el Producto en general (impacto estratégico y de negocio):

•       Lograr un aumento del 15 % en el Net Promoter Score (NPS) de los comerciantes que utilizan la plataforma en los próximos 6 meses.

•       Aumentar la tasa promedio de conversión de visitantes a compradores en las tiendas de los comerciantes de la plataforma en un 5 % en el próximo trimestre.

•       Disminuir la tasa de abandono de comerciantes (“churn rate”) en un 10 % en el semestre.

•       Un incremento del 20 % en el volumen total de transacciones procesadas a través de la plataforma en los próximos 6 meses.

Para un Objetivo de Producto específico (por ejemplo, "Mejorar la capacidad de los comerciantes para gestionar inventarios"):

•       Disminuir el tiempo promedio que le toma a un comerciante actualizar y gestionar su inventario en la plataforma en un 25 %.

•       Reducir en un 30 % la cantidad de quejas de clientes relacionadas con productos "agotados" que aparecen como "en stock" en las tiendas.

•       Un 50 % de los comerciantes activos han configurado y reciben alertas de bajo stock para sus productos clave.

Mientras que la Definición de Producto Terminado adyacente puede incluir:

•       Código revisado y aprobado

•       Pruebas unitarias exitosas con una cobertura mínima del 80 %.

•       Pruebas de integración y sistema pasadas

•       Pruebas de regresión automatizadas

•       Desplegado en el entorno de preproducción

•       Rendimiento y escalabilidad verificados

•       Seguridad validada

•       Compatibilidad con navegadores y dispositivos principales (Chrome, Firefox, Safari, iOS, Android).

•       Documentación técnica actualizada

Nada que no esté incluido en una Definición de Terminado típica.

Diferencias clave

En esta tabla te dejo de manera sucinta algunos aspectos que te pueden ayudar a entender sobre el enfoque, el alcance, la validación y el momento de verificación de cada una de estas definiciones de Terminado.

	Definition of Output Done (Definición de Producto Terminado)	Definition of Outcome Done (Definición de Resultado Terminado)
Enfoque	Se enfoca en la calidad de la entrega (el "qué" se construyó)	Se centra en el valor o impacto logrado (el "porqué" se construyó).
Alcance	Aplica a un Incremento específico, asegurando que está listo para ser potencialmente lanzado.	Aplica al Producto en general o a una meta estratégica, midiendo si el Producto genera los beneficios esperados a lo largo del tiempo.
Validación	Se valida mediante criterios de calidad internos y técnicos (pruebas, revisiones de código).	Se valida mediante evidencia observable de impacto en los Stakeholders (métricas de negocio, comportamiento del usuario, encuestas de satisfacción) una vez que el output ha sido liberado y utilizado.
Momento de Verificación	En cada Sprint para cada Incremento.	Proceso continuo que ocurre a medida que el Producto interactúa con el mercado y los usuarios a lo largo del tiempo.

 Recomendación final

Entregar un producto perfecto que no genera valor es el fracaso más elegante del mundo. Inapelable. Si hoy tienes una Definición de Terminado con la que has tenido éxito entregando valor e impactando el negocio sprint tras sprint, entonces quizás no necesites nada de lo que hay aquí. Aun así, es una buena propuesta.

Si, por el contrario, tus usuarios o clientes continúan sin ver los beneficios de lo que les entregas, entonces quizás sea buena idea empezar a usar estos dos compromisos por separado. Como te dije al principio: empieza experimentando en pequeño, con un equipo, observa los resultados, las reacciones del entorno, aprende. Reflexiona. Y adáptate.

Si tienes algún inconveniente, siempre puedes contactarme y, en la medida de mis posibilidades, con gusto te ayudo.

Bajo el mando de un loro parlanchín: la gran ilusión de la IA pensante

 

La inteligencia artificial vive una época dorada de atención mediática y expectativa popular. No hay semana sin una nueva declaración de que estamos "cerca" de la AGI (inteligencia artificial general), sin titulares que anuncian que una IA fue nombrada CEO, sin startups valoradas en millones por usar un bot que escribe correos o genera código. Pero... ¿pensamos realmente en lo que significa "inteligencia"?

Lo realmente hermoso de todo esto es que estamos aprendiendo a pasos enormes. Hace poco escribía "El día en que la IA se volvió prescindible… de nosotros" y "¿El fin de la Ingeniería de Software como la conocemos?" que puedes encontrar en este mismo Gazafatonario y donde exponía, basado también en sendas investigaciones, el poder de la IA y cómo esta herramienta (que no deja de serlo) se está desligando cada vez más de nosotros, los seres humanos.

Ahora iré por otro camino. Y es que una investigación reciente, "La ilusión de pensar" de Apple*, desnuda las limitaciones actuales de estos modelos de lenguaje que tanto nos fascinan. A través de pruebas estructuradas como la Torre de Hanoi, juegos de fichas o rompecabezas lógicos, los investigadores demostraron que, al aumentar un poco la complejidad de la tarea, estos sistemas colapsan. No se equivocan un poco: fallan por completo.

Vamos un poco más allá.

El loro que parece pensar

Imagina un loro muy entrenado. Puede repetir frases con una entonación asombrosa, puede imitar una conversación humana, e incluso lanzar frases graciosas. Pero no sabe lo que dice. No comprende el significado de "llama a un taxi" o "aprueba el presupuesto". Solo asocia patrones de sonidos con recompensas. Esa es, en esencia, la forma en que operan los grandes modelos de lenguaje: predicen la siguiente palabra probable en una cadena, sin comprender el contenido como lo hace un humano.

Entonces, ¿cuándo un loro deja de ser loro y se convierte en pensador? La respuesta no está en la cantidad de palabras que puede decir, sino en si puede razonar, planificar, corregirse, ejecutar una idea paso a paso y adaptarse cuando algo falla. Y ese es justamente el terreno donde los modelos actuales tropiezan.

Ese es el meollo del trabajo de Apple. El estudio señala un fenómeno curioso: cuando enfrentan tareas simples, los modelos de IA que supuestamente razonan, mediante la generación de cadenas de pensamiento paso a paso, tienden a extender innecesariamente su "pensamiento", buscando más de lo necesario y a veces terminando en error. Y cuando la tarea se vuelve realmente compleja, en lugar de esforzarse más, tienden a recortar su razonamiento.

Me recuerda a muchos estudiantes que he tenido o acompañado, quienes, frente a un problema difícil, tomaron la decisión de pensar menos en lugar de más. Pero con las IA no solo pasa eso. Incluso cuando se les entrega el algoritmo exacto para resolver el problema, muchos modelos no logran ejecutarlo bien. No es cuestión de no saber qué hacer, sino de no saber hacerlo bien.

CEO artificial o placebo tecnológico

Ahora volvamos a esas startups que han ensayado poner una IA como CEO. Sin duda alguna suena futurista, radical. Pero si entendemos que esa IA no tiene conciencia, ni juicio propio, ni capacidad para razonar sobre el largo plazo, ni responsabilidad legal, la designación es solo decorativa. Es como poner una estatua de Einstein al frente de un laboratorio y decir que él toma las decisiones o hace los experimentos. Al final, son humanos quienes entrenan al modelo, diseñan sus datos de entrada y deciden cuándo y cómo usar sus respuestas. El "CEO" artificial no tiene ni voluntad ni intención. No gestiona. Es gestionado. No lidera.

Decir que estamos cerca de una AGI porque una IA responde como humano en una entrevista o redacta un ensayo aceptable es tan ingenuo como creer que Siri es médico por decirnos que tomemos agua cuando tenemos tos.

El verdadero poder (y uso) de la IA hoy

Otra vez: no me entiendas mal. La IA es la herramienta más poderosa que la humanidad ha inventado. No tengo ninguna duda de ello. Ya hay algunas por allí que pueden detectar patrones invisibles al ojo humano en medicina y revelar algo tan complejo como un cáncer o incluso predecir tu siguiente estado de salud. Y, en general, lo más alucinante de la IA es que te hace mejor en lo que haces.

Pero no estamos cerca de una máquina que piense como yo o como tú o como un niño pequeño. Sin embargo, eso no significa que la IA actual sea irrelevante. Al contrario, su poder precisamente está en que puede amplificar nuestras capacidades humanas, no reemplazarlas. Puede ayudarnos a escribir más rápido, resumir grandes cantidades de información o generar opciones creativas. Pero necesita dirección, juicio, supervisión.

Usar IA como copiloto tiene sentido. Usarla como piloto es, por ahora, una apuesta ciega.

El estudio que he señalado dice que debemos enfocar la evolución de estos sistemas en mejorar su capacidad de ejecución precisa, su comprensión real de reglas lógicas, su habilidad para planificar y corregirse, y en entender cómo y cuándo usar cadenas de pensamiento. Hay que ir más allá del “hype”, de la fascinación superficial por respuestas fluidas y mirar si realmente hay comprensión detrás.

Eso sí, como civilización, corremos el riesgo de enamorarnos de una fantasía: sentir que ya creamos una inteligencia capaz de pensar, decidir y liderar. Pero el pensamiento verdadero no es repetir respuestas correctas, sino saber por qué algo es correcto, saber cambiar de opinión ante nueva evidencia, saber decir "no sé" y aprender. Y eso, por ahora, está muy lejos del alcance de cualquier IA disponible.

Así que es definitivo: cuando los ecos se confunden con voces, dejamos de escuchar. Y cuando el algoritmo simula pensamiento, corremos el riesgo de obedecer al eco creyendo que razona... La inteligencia del futuro no se medirá por lo que dice, sino por lo que es capaz de entender, cambiar y construir.

 

*“The Illusion of Thinking: Understanding theStrengths and Limitations of Reasoning Models via the Lens of ProblemComplexity”.

 

Podcast

Como siempre, aquí puedes escuchar una breve explicación del artículo, pero, sobre todo, del trabajo de los investigadores de Apple. 

La burbuja de la innovación predictiva: más allá del miedo al futuro

 

En 1997, un joven ingeniero de software, convencido de que podía transformar la experiencia del cliente en el sector del alquiler de películas, propuso una idea radical para la época: ofrecer un servicio de alquiler de videos por internet, con envío físico a domicilio. Blockbuster, el líder indiscutido del mercado, respondió bajo una lógica profundamente conservadora: "Muéstranos que ya funciona en otro lado". Esa exigencia de validación externa, ese miedo disfrazado de prudencia, fue su sentencia. Mientras Netflix abrazaba la exploración, Blockbuster quedaba atrapado en la explotación de su modelo, condenándose lentamente a la irrelevancia.

Este momento no es solo una anécdota corporativa del pasado. Me gusta contarla en mis charlas sobre experimentación e innovación porque es una advertencia viva que muchas organizaciones actuales siguen ignorando. El espejo del pasado refleja oportunidades perdidas por miedo al qué dirán, a la falta de precedentes o al deseo incontrolable de certezas.

El espejismo de la innovación sin riesgo

Hoy, a pesar de que los discursos empresariales están repletos de términos como disrupción, design thinking, agilidad, transformación digital y cultura de la innovación, en la práctica seguimos viendo decisiones que priorizan la predictibilidad sobre el potencial. Se pide a los equipos que imaginen lo inédito, pero bajo la condición de que haya antecedentes. Se alienta a crear lo que nadie ha hecho, pero solo si alguna empresa exitosa ya lo intentó antes. Esta paradoja nutre un fenómeno organizacional crónico: la burbuja de la innovación predictiva.

Esta burbuja es una cámara de aislamiento que impide el verdadero salto innovador porque se rehúsa a aceptar que el riesgo y la incertidumbre son parte esencial del ADN de lo nuevo. Representa una tensión epistemológica entre dos lógicas organizacionales: la de la exploración y la de la explotación. En breve, es el deseo corporativo de recorrer territorios desconocidos sin alejarse del mapa. Una contradicción que, cuando no se reconoce, lleva a las organizaciones a simular innovación sin realmente practicarla.

Es como pedirle a un chef que invente un plato completamente nuevo, inédito y memorable, pero solo si ese plato ya fue aprobado previamente por los críticos gastronómicos de París y Tokio. La analogía refleja de manera simple el abismo entre lo que se proclama en las salas de reuniones y lo que realmente se permite en la operación diaria.

El teatro de la innovación corporativa

Esta incoherencia se manifiesta cada día en los entornos de trabajo. A los equipos se les pide que piensen como startups, que actúen con agilidad, que adopten tecnologías emergentes, pero se les impone una planificación cerrada, con indicadores heredados del siglo pasado. Se promueve el lenguaje de la experimentación, pero se castiga el error. Se solicita innovar con inteligencia artificial generativa, realidad aumentada o modelos novedosos y, sin embargo, los primeros cuestionamientos que surgen en la sala son sobre el cumplimiento normativo, los casos de uso ya validados o la falta de referentes que justifiquen la inversión.

La innovación se practica, no se promete

La innovación verdadera no surge de la extrapolación del pasado. No es una proyección lineal de lo que ya funcionó. La innovación real emana de la capacidad de experimentar, de diseñar entornos controlados donde la incertidumbre se convierte en un insumo valioso. Innovar implica iterar, fallar, observar, adaptar. Implica abandonar el mito de la genialidad instantánea y reemplazarlo por el rigor del aprendizaje continuo. Requiere pasar de una cultura de control a una cultura de aprendizaje, en la que el error no se castiga, sino que se analiza y hasta se premia.

En este enfoque, los experimentos no se diseñan solo para confirmar una hipótesis, también para aprender de lo inesperado. La innovación, en su forma más pura, es una práctica de humildad cognitiva. Es el reconocimiento de que, para crear algo realmente nuevo, debemos aceptar no saber. Y esa aceptación es profundamente turbulenta en culturas organizacionales obsesionadas con el control.

Romper la burbuja: un imperativo estratégico

El futuro, por definición, no está escrito. No puede repetirse porque no ha ocurrido. Por eso no puede validarse con estadísticas del pasado. Debe descubrirse a través de procesos que admitan lo desconocido como condición. Romper la burbuja de la innovación predictiva no es solo recomendable: es indispensable para cualquier organización que aspire a mantenerse relevante en la próxima década.

Esto implica rediseñar los sistemas de gobernanza, repensar los criterios de inversión en proyectos, resignificar el papel del liderazgo y reentrenar a los equipos para operar en entornos donde el éxito no está garantizado, pero donde el aprendizaje está asegurado. Significa dejar de preguntarse "¿quién más lo hizo?" para comenzar a preguntarse "¿qué podríamos aprender si somos los primeros en intentarlo?"

Finalmente, la verdadera capacidad innovadora no reside solo en detectar la próxima gran idea, sino además en crear entornos estructurales, culturales y operativos que permitan que esas ideas emerjan, evolucionen y se validen rápidamente. El liderazgo del futuro no será el que controle más variables, sino el que habilite más posibilidades. La capacidad de innovar dependerá menos de tener la respuesta correcta y más de hacer las preguntas adecuadas en el momento correcto.

La innovación no se pronostica. Se practica. Se arriesga. Se encarna. Y solo quienes entiendan esto, estarán realmente preparados para inventar el futuro.

La ciencia del progreso: Navegando el cambio con métricas, OKR, KPI y modelos de madurez

 La ciencia del progreso: Navegando el cambio con métricas, OKR, KPI y modelos de madurez

Hoy por hoy, los equipos digitales avanzan a velocidad “cuántica” y están inmersos en escenarios donde no medir es navegar sin instrumentos. Pero medir por medir, sin dirección ni propósito, es igual de peligroso. Las métricas, los OKR (Objectives and Key Results), los KPI (Key Performance Indicators) y los modelos de madurez no son solo herramientas: son sistemas vivos que nos ayudan a hacer visibles los patrones del progreso.

Estas herramientas se articulan y complementan y pueden usarse de forma estratégica para potenciar procesos de mejora continua, impulsar la innovación y alinear a toda la organización hacia un propósito común. Mi primer mensaje aquí es “mide para mejorar”, incluso voy a ir más allá: “mide solo para mejorar”. Axiomático.

Métricas que importan: Menos es más (si mides lo correcto)

Las métricas no son todas iguales. Algunas reflejan directamente el estado del negocio, otras el impacto real del producto sobre los usuarios, y otras el funcionamiento interno del equipo de trabajo (métricas de proceso o flujo). Entender esta diferencia es clave para seleccionar aquellas métricas que realmente generen valor.

Ejemplos prácticos:

• Métrica de negocio: Tasa mensual de retención de clientes.
• Métrica de producto: Porcentaje de usuarios activos que utilizan una nueva funcionalidad.
• Métrica de equipo: Tiempo promedio desde que se inicia hasta que se entrega una funcionalidad (lead time).

Criterios para buenas métricas:

• Deben influir activamente en la toma de decisiones estratégicas o tácticas.
• Son consistentes y comparables a lo largo del tiempo.
• Pueden ser influenciadas o gestionadas directamente por los equipos responsables.

Es definitivo, una métrica sin contexto es como una fiebre sin diagnóstico: te alarma, pero no sabes qué hacer.

KPI y OKR: herramientas complementarias, no intercambiables

A grandes rasgos, OKR (Objectives & Key Results) es un marco de fijación de metas que combina un objetivo cualitativo (“qué queremos lograr”) con resultados clave cuantitativos (“cómo mediremos el progreso”). Su propósito es impulsar la ambición y la innovación, alineando a la organización en torno a retos inspiradores y medibles.

Entre tanto los KPI (Key Performance Indicators) son métricas operativas que siguen el desempeño de procesos críticos y el estado de salud del negocio y su propósito esmonitorear y mantener resultados clave del día a día, garantizando estabilidad y eficiencia.

En otras palabras, los KPI son indicadores de salud. Los OKR son marcos de ambición. Mientras que los KPI están diseñados para vigilar, en el sentido de gestionar, el desempeño continuo y asegurar la estabilidad operativa, los OKR están orientados a provocar el cambio, establecer metas visionarias y fomentar la alineación estratégica.

Por ejemplo, si diriges un restaurante, un KPI puede ser “Tasa de ocupación del 80 %” y un OKR sería: “Objetivo: Convertirnos en el restaurante más recomendado de la zona. Resultado clave: Aumentar reseñas 5 estrellas de 120 a 200 en 3 meses.”

Para saber más sobre OKR puedes ver mi presentación introductoria:

Conociendo OKR - Gazafatonario IT.

También mi artículo: La furia de los OKR - Gazafatonario IT.

Y este otro, donde propongo un modelo en forma de pirámide de cuatro niveles: OKR y la estrategia emergente en la empresa moderna – Lucho Salazar.

Tabla comparativa:

Aspecto	OKR	KPI
Propósito	Generar cambio significativo	Evaluar desempeño sostenido
Horizonte	Temporal, evolutivo, por ciclos, adaptativo	Continuo, estable, de seguimiento
Ambición	Inspiradores, retadores y visionarios	Realistas, específicos y controlables
Naturaleza	Orientados a resultados clave transformacionales	Basados en indicadores constantes y operativos

Usa OKR para mover la aguja, es decir, para provocar movimiento estratégico con metas claras. Usa KPI para saber si la aguja vibra, o sea, para observar estabilidad operativa y mantener el pulso del negocio.

Modelos de madurez: El mapa no es el territorio, pero ayuda a cruzarlo

Los modelos de madurez describen etapas progresivas en áreas clave como liderazgo, tecnología, cultura, procesos, agilidad y capacidades de aprendizaje organizacional. Aunque no sustituyen la realidad, ofrecen una guía clara para comprenderla y diseñar un camino evolutivo sostenible.

Ejemplo simple:

• Nivel 1: El equipo depende de un solo experto. Todo es manual.
• Nivel 3: Hay roles claros, automatización básica y retrospectivas frecuentes.
• Nivel 5: Uso de IA para toma de decisiones, aprendizaje continuo y cultura de datos.

Usos recomendados:

• Diagnóstico inicial en procesos de transformación digital o cultural.
• Diseño y planificación de programas de mejora continua.
• Identificación de obstáculos estructurales, tecnológicos o culturales.

Advertencia: No se trata de llegar al nivel máximo por ego. Se trata de estar en el nivel adecuado para el valor que deseas entregar, esto es, que mejor potencie el impacto esperado y que sea sostenible. Pero más importante, cuando se trate de modelos de madurez, no subestimes tu poder humano, y “humanizante”, de pensar

Sincronización inteligente: OKR + KPI + Madurez = Síntesis operativa

Pensemos en esto como una orquesta:

• Los KPI son los sensores del sistema. Nos dicen si estamos vivos.
• Los OKR son las partituras. Nos dicen hacia dónde queremos ir.
• El modelo de madurez es el manual del instrumento. es el conocimiento técnico, permite saber si estamos tocando con competencia o aún estamos en aprendizaje.

Ejemplo combinado:

• Modelo de madurez indica que el equipo está en Nivel 2 en "automatización".
• KPI: Tasa de errores poslanzamiento = 12 %.
• OKR: Objetivo: Reducir los errores por despliegue. Resultado Clave: Aumentar pruebas automatizadas de 25 % a 70 % en 3 meses.

Entra la inteligencia artificial como motor de evolución ágil

Los equipos ágiles de alto rendimiento ya están incorporando herramientas de inteligencia artificial para aumentar su capacidad adaptativa y su velocidad de entrega.

Aplicaciones actuales:

• Predicción de riesgos en ciclos de entrega.
• Recomendaciones automáticas para priorización de tareas y funcionalidades.
• Automatización de tareas técnicas y de pruebas repetitivas.

Un caso que ya volvimos “típico” es el de los equipos que utilizan IA para identificar historias de usuario duplicadas o de bajo valor en el backlog, ahorrando un porcentaje de tiempo significativo de refinamiento en cada sprint. En este escenario, la métrica asociada es la reducción mensual de historias descartadas después de haber sido priorizadas.

Y como siempre, aunque ya suene a cliché, toca decirlo, por el estrés que está causando la incorporación de la IA en nuestras vidas, sobre todo en el trabajo: La IA no reemplaza al equipo; lo aumenta, lo potencia, mejora su capacidad de análisis y libera tiempo para tareas de mayor impacto.

Errores comunes (y cómo evitarlos)

No me voy a andar por las ramas, seguimos cometiendo muchos errores cuando de métricas, OKR, KPI y modelos de madurez se trata. Por eso escribí La furia de los OKR - Gazafatonario IT. Además de lo que mencioné allí, aquí hay solo algunos otros:

1. Confundir resultados clave con tareas: Un resultado clave debe ser un cambio observable y cuantificable, no simplemente la ejecución de una acción.
2. Enamorarse de métricas vanidosas: No basta con medir visitas a una web; hay que medir si esas visitas se traducen en conversiones o valor real.
3. Usar solo encuestas para medir madurez: Combina percepciones subjetivas con datos y evidencias objetivas.
4. Definir KPI sin una línea base: Sin un punto de partida, es imposible saber si estamos avanzando o retrocediendo.
5. Copiar modelos ajenos sin adaptación al contexto: Cada organización tiene su cultura, mercado y desafíos. Ajusta cualquier modelo antes de adoptarlo.

Conclusión y llamado a la acción

Mide lo que transforma, no solo lo que cuenta. La agilidad no se define por la velocidad o la cantidad de entregas, sino por la capacidad de aprender, adaptarse y evolucionar de forma continua. Las métricas, los OKR, los KPI y los modelos de madurez forman un sistema interconectado que permite traducir aspiraciones estratégicas en acciones concretas, medibles y sostenibles.

Te invito a:

• Establecer al menos un OKR estratégico por trimestre que oriente el cambio.
• Monitorear de manera constante tres KPI clave que reflejen la estabilidad operativa.
• Evaluar periódicamente tu madurez organizacional en cinco dimensiones esenciales.
• Explorar cómo integrar herramientas de inteligencia artificial en tus flujos de trabajo y procesos de decisión.

No lo olviden, la madurez se alcanza cuando medimos para evolucionar, no solo para controlar. ¿Algo más? Por favor, déjamelo saber en el foro.

Post scriptum

Puedes escuchar una explicación sucinta de todo esto en mi podcast gracias a los amigos de Google NotebookLM.

Y puedes ver y descargar la presentación que hiciera hace poco. Con más ejemplos y datos. Y donde presento dos modelos de madurez para nuestro tiempo, uno para equipos y organizaciones y otro para personas, "De Novatos a Nindō (忍道)".

El Poder del “¿Y si…?”

 𝗘𝗹 𝗽𝗼𝗱𝗲𝗿 𝗱𝗲𝗹 “¿𝗬 𝘀𝗶…?”

Esta semana, en una reunión de trabajo con un cliente potencial, la dinámica era un déjà vu corporativo: presentación predecible, acuerdos tibios, nadie saliéndose del libreto. Sin pensarlo mucho, quizás impulsado esa curiosidad innata que siempre he tenido, lancé un: “¿Y si en lugar de cerrar esto aquí invitamos a tu cliente a decidir con nosotros en vivo?”. Silencio. Pero sentí que esta vez era distinto. Fue un silencio que hacía espacio. Me di cuenta de que era un silencio que abría puertas.

Y es que, en medio de la rutina laboral, entre informes, entregables y reuniones, hay una pregunta que puede abrir grietas en la lógica establecida: “¿Y si…?”. Dos palabras que son una llave maestra. Porque donde el procedimiento dice "así se hace", el ¿y si...? dice "¿por qué no diferente?".

Vivimos ahogados en eficiencia. Se premia la repetición que funciona, el camino probado. Pero eso también construye ceguera. La costumbre se convierte en trinchera. Es ahí donde el “¿y si…?” funciona como un bisturí: corta la inercia, descompone lo obvio y deja al descubierto posibilidades que nadie ve porque todos están mirando igual.

En mi experiencia, pocas frases generan tanto silencio incómodo en una sala como un “¿y si…?” bien lanzado. Es una bomba chiquita que detona certezas. ¿Y si los clientes diseñaran el producto con nosotros? ¿Y si los lunes fueran sagrados para no tener reuniones? ¿Y si la competencia no fuera amenaza sino insumo?

Es el equivalente a ese colega o socio que, justo cuando crees que ya finalizaron un trabajo, cuando hay una versión final del producto, dice: “¿Y si probamos otro enfoque?”. Al principio irrita. Luego ilumina. Porque la mayoría de las soluciones memorables nacieron de un deslizamiento: alguien se salió del carril.

La analogía es simple: piensa en un escritorio de oficina. Siempre ordenado igual. Los lapiceros a la izquierda, el cuaderno al centro, la taza de café al borde derecho. Ahora, un día, alguien mueve todo de sitio. Y sin darte cuenta, te obliga a mirar de nuevo, a adaptarte, a reevaluar lo que dabas por sentado. Eso es el “¿y si…?”: reordenar el escritorio mental.

Hazlo costumbre. Una vez al día. Al revisar un proceso, al liderar una conversación, al evaluar una decisión. Pregunta: “¿Y si lo hiciéramos al revés? ¿Y si quitamos esto? ¿Y si lo hacemos más simple?”. No siempre cambiarás el mundo, pero entrenarás tu mirada para encontrar lo que otros pasan por alto.

El ‘¿y si…?’ es la primera contracción de una idea viva. No grita, no empuja, no impone. Susurra. Pero si la escuchas, puede partir tu mundo en antes y después.