Este es mi punto de vista sobre las Tecnologías de la Información, Software y Pensamiento Ágil. Especialmente en lo que respecta a procesos y métodos, modelos y sistemas, marcos de trabajo y prácticas ágiles, experiencia en la industria, transformación organizacional, cultura, generación de Valor, trabajo colaborativo, Inspección y adaptación y mejoramiento continuo. Propuestas y experimentos, mejores prácticas y calidad de los productos (de software) y servicios.
(Antiguo gazafatonarioit.com)
Exigir resultados a una persona, a un equipo, no los garantiza.
Este era uno de mis mantras desde hace 2 décadas o más. Era un escenario típico con jefes y "líderes" que traían arraigadas prácticas de gestión del siglo pasado, incluso del anterior a ese.
Pero sigue vigente, en pleno último trimestre de 2026. Y no, exigirle resultados a un equipo agéntico o a un equipo humano apoyado con IA no logra mágicamente que eso suceda. Ni siquiera con todo el poder actual de la inteligencia artificial.
Lo que sí funciona es el trabajo colaborativo, la inteligencia colectiva, el "meterse en el barro" junto con la orden o la idea, la comunicación bidireccional, el "te doy el tiempo que necesitas".
Pero ojo, eso tampoco quiere decir que "empezamos y en el camino vamos arreglando las cargas". La planificación -la "buena" planificación- está más vigente que nunca. Y el compromiso. Y el darlo todo por lograr un objetivo. Y el solicitar ayuda cuando lo veas necesario. Otro de mis mantras de siempre.
Hace poco finalizó la vuelta ciclística a España. Ya había
escrito un artículo sobre la falacia del superhéroe multitarea y el costo
oculto del «Siempre lo hemos hecho así», a propósito de una peligrosa práctica
que realizan los directores de equipos ciclísticos que conducen los autos de
los equipos.Puedes encontrar el
artículo en:
Pues bien, en la penúltima etapa, un ciclista colombiano, Egan
Bernal, fue sancionado por la práctica conocida como bidón pegado o
pegajoso, un truco donde el auto del director se acerca, transfiere el
bidón al ciclista y ambas manos “se pegan” al envase para dar al deportista un
empujón extra, una maniobra que la organización considera como ventaja
irregular y por la que Bernal recibió la multa.
Esto me recordó cómo hoy por hoy el “pelotón” corporativo
avanza a ritmo frenético. Las métricas de productividad marcan el paso, los KPI
dictan la cadencia, y en medio de esta carrera desenfrenada, aparece el auto del
equipo con una solución aparentemente salvadora: la inteligencia artificial.
Como en el incidente que protagonizó Egan Bernal en la Vuelta a España, en más
de treinta años de experiencia he visto cómo en las organizaciones hay una
línea delgada entre la asistencia legítima y el dopaje tecnológico. Con la IA,
esa raya es cada vez más tenue.
Pensémoslo un poco. El CEO es el director deportivo, ansioso
por resultados inmediatos. La solución de IA de turno es el carro del equipo,
prometiendo velocidad y eficiencia. El bidón representa esas intervenciones
puntuales: prompts prefabricados, automatizaciones express, dashboards
predictivos. Y el ciclista agotado es el equipo humano, aferrándose con
desesperación a cualquier cosa que le permita mantener el ritmo insostenible
que exige el mercado.
Cuando la mano humana y la mano algorítmica quedan
"pegadas" al mismo bidón digital, la organización experimenta una
aceleración instantánea. Los informes se generan en segundos, el código se
autocompleta, las decisiones se "optimizan" con modelos predictivos. En
el corto plazo, parece una jugada maestra: las métricas suben, los costos
bajan, los inversionistas aplauden. Pero este empujón artificial tiene un
precio que pocas organizaciones están calculando.
Primero, está la atrofia de capacidades. Cuando los equipos
dependen del "empujón" de la IA, sus músculos intelectuales se
debilitan. La capacidad de análisis crítico, la creatividad para resolver
problemas, el juicio profesional cultivado durante años: todo se erosiona
cuando la respuesta siempre viene premasticada por un algoritmo. Es como el
ciclista que olvida cómo remontar por sus propios medios porque siempre cuenta
con el auto del equipo.
Segundo, surge una dependencia invisible pero peligrosa. ¿Qué
sucede cuando el proveedor de IA cambia sus términos, cuando la regulación
endurece las condiciones de uso, cuando un fallo técnico deja a la organización
sin su muleta digital? El corredor queda solo en la carretera, sin la
resistencia ni la técnica para continuar al ritmo que el mercado exige.
Tercero, aparecen las consecuencias éticas y reputacionales.
Así como Bernal enfrentó multa y críticas, las organizaciones que abusan del
"bidón pegado" digital enfrentan escrutinio regulatorio, pérdida de
confianza del consumidor y cuestionamientos sobre la autenticidad de sus
logros. ¿Es realmente innovación cuando el mérito es del algoritmo? ¿Qué valor
tiene una victoria conseguida con ventaja artificial?
Está sucediendo a tutiplén. Empresas sancionadas por
tratamiento indebido de datos biométricos [1], Amazon debió retirar su sistema
de filtrado curricular cuando se identificó que discriminaba por género, al
basarse en datos históricos sesgados [2]; bancos y otras empresas han sido
víctimas de estafas donde directivos falsos, generados por IA en videollamadas,
lograron transferencias millonarias, afectando la confianza y reputación de las
compañías afectadas [3]; la manipulación de reseñas y opiniones en línea
mediante IA pone en duda la legitimidad de la reputación digital de empresas y
productos, deteriorando la confianza de los consumidores [4], entre muchos
otros ejemplos son apenas la punta del iceberg de lo que está ocurriendo a raíz
de esta ya infame práctica del “bidón pegajoso de la IA”.
Evidentemente, la solución no es prohibir la IA,
debilitar su uso, ni mucho menos no usarla, sería como pretender eliminar los carros
del ciclismo profesional. La IA es la herramienta más poderosa que la humanidad
ha inventado, entonces lo que toca es redefinir las reglas del juego,
establecer límites claros entre asistencia y dependencia, entre herramienta y
muleta. Las organizaciones necesitan entrenar la resistencia cognitiva de sus
equipos, mantener viva la capacidad de pensar y crear sin asistencia algorítmica,
usar la IA como hidratación estratégica, no como propulsión artificial.
Es simple: cuando tu organización no puede funcionar sin el
bidón pegado de la IA, no has construido ventaja competitiva: has comprado
tiempo prestado. Y en el futuro próximo, las empresas que sobrevivan no serán
las que mejor sepan agarrarse al algoritmo, sino las que aprendan a pedalear en
el vacío cuántico donde la inteligencia artificial se vuelve tan ubicua que
deja de ser diferenciador. La verdadera disrupción no es adoptar la IA; es
saber competir cuando todos la tienen y nadie puede usarla como excusa.
Las carreras de ciclismo me parecen
muy emocionantes. Me apasiona verlas. Pero imagina esto: un director deportivo
conduciendo a 50 km/h por una carretera sinuosa de montaña, rodeado de miles de
espectadores eufóricos, mientras simultáneamente entrega un bidón a un ciclista
o una barra energética, grita instrucciones tácticas por radio y calcula
mentalmente los tiempos de carrera. Todo esto mientras "conduce" un
vehículo de dos toneladas. ¿Suena demencial? Bienvenido al mundo del ciclismo
profesional, donde esta práctica suicida se defiende con el argumento más
peligroso de la historia empresarial: el infame "siempre lo hemos hecho
así".
Esta locura ciclística es el
espejo perfecto de lo que está destruyendo silenciosamente nuestras
organizaciones tecnológicas. Y no, no estoy exagerando.
En el desarrollo de software
moderno, especialmente en entornos "ágiles", vemos el mismo patrón
destructivo. El Product Owner que está en cuatro reuniones simultáneas mientras
"define" la hija de ruta del producto. El Scrum Máster que facilita
retrospectivas mientras programa y hace pruebas "para ayudar al
equipo". El líder técnico que hace revisión de código mientras está en una
llamada con el cliente explicando por qué el sprint falló... otra vez.
¿El resultado? El mismo que
cuando el director ciclista inevitablemente choca: desastre total. Solo que en
nuestro caso no son huesos rotos, son productos digitales que nacen muertos,
equipos quemados y millones en alguna moneda evaporados en iniciativas que
nunca debieron existir.
Pero la multitarea tiene un costo
mucho más grave, uno que prácticamente es irrecuperable. Para saber cuál es,
por favor, lee mi artículo El
verdadero costo de la multitarea en mi Gazafatonario:
Ahora les hablaré de otro costo oculto
en nuestras prácticas tradicionales.
El costo oculto del "Siempre lo hemos hecho así"
Aquí viene la parte que duele:
las organizaciones que presumen de ser "ágiles" y "lean"
son las peores infractoras. Han convertido los marcos de trabajo en religiones,
los roles en títulos nobiliarios y los eventos en rituales vacíos.
Lo escucho a cada rato, con aire
de orgullo: "Mi CTO está en las reuniones importantes, revisa todo el
código y además lidera la estrategia de IA". Al preguntar: "¿Y cuándo
piensa?", el silencio se hace incómodo. Porque claro, pensar no está en el
backlog.
La ironía salta a la vista. Lean
nos enseña a eliminar desperdicios, pero mantenemos a nuestros mejores talentos
haciendo malabarismo con tareas incompatibles. Scrum habla de foco y
compromiso, pero nuestros Product Owners están tan dispersos que no podrían
reconocer una propuesta de valor ni aunque les pegara fuerte en la cara.
No creas que la IA no va a salvarte, va a exponerte. Y es que,
con la explosión de la IA generativa, la situación se vuelve tragicómica. Veo
equipos implementando GitHub Copilot mientras su arquitectura base es un
desastre o gerentes pidiendo "meter IA" en productos que aún no
logran encajar en el mercado.
La IA amplifica. Si tu proceso de
desarrollo es caótico, la IA lo hará caóticamente más rápido. Si tu Product
Owner no entiende el problema del usuario, ChatGPT le ayudará a no entenderlo
con párrafos más elegantes.
El antídoto: separación radical de responsabilidades
Imagen generada por IA
Volvamos al ciclismo por un
segundo. La solución es simple: el conductor conduce, punto. Otro miembro del
equipo maneja la logística con los ciclistas. ¿Revolucionario? No. ¿Sensato?
Absolutamente. En nuestras organizaciones tecnológicas, necesitamos la misma
claridad brutal:
El Product Owner debe
obsesionarse con el usuario. No con Jira, no con las reuniones diarias, no
con el código. Su trabajo es entender tan profundamente al usuario que pueda
predecir sus necesidades antes que ellos mismos. Si está en más de dos eventos al
día, hay síntomas de intoxicación.
El Scrum Máster facilita, no
ejecuta. Si está probando, no está observando las dinámicas del equipo. Es
como un psicólogo que está tan ocupado tomando pastillas que no escucha a sus
pacientes.
Los desarrolladores
desarrollan. No están en reuniones de estrategia de negocio. No están
vendiendo al cliente. Están resolviendo problemas técnicos complejos, lo cual,
sorpresa, requiere concentración profunda y tiempo ininterrumpido.
Intenta lo siguiente: imagina que
cada vez que alguien en tu organización hace multitarea con responsabilidades
críticas incompatibles, está literalmente conduciendo un carro a alta velocidad
mientras mira el celular. ¿Cuántos accidentes tendrías al día?
Ese error crítico en producción
que costó mucho en ventas perdidas: accidente por conducir distraído. Esa funcionalidad
que nadie usa después de 6 meses de desarrollo: choque frontal por no mirar la
carretera. Ese equipo estrella que renunció en masa: volcadura por intentar
cambiar de carril en zona prohibida.
Las organizaciones que
sobrevivirán la próxima década no serán las que tengan la mejor tecnología o
los frameworks más modernos. Serán las que tengan el coraje de decir:
"Esto que hacemos es estúpido y peligroso, y vamos a parar".
Serán las que entiendan que un
Product Owner enfocado vale más que diez "haciendo de todo un poco".
Que un equipo de desarrollo con 4 horas diarias de concentración profunda
produce más valor que uno en reuniones perpetuas. Que la IA es una herramienta,
no una varita mágica.
Mi advertencia final
Si tu organización sigue operando
como el director ciclístico, haciendo malabarismo con responsabilidades
críticas incompatibles mientras acelera hacia el futuro, la sacudida será
inevitable. La única pregunta es: ¿será un raspón del que puedan recuperarse, o
será el accidente que los saque definitivamente de la carrera?
El ciclismo profesional puede
darse el lujo de ser torpemente tradicional porque el espectáculo vende. Tu empresa
no tiene ese privilegio. En el mundo del desarrollo de productos digitales, los
dinosaurios no se extinguen lentamente; desaparecen en un trimestre malo.
Así que la próxima vez que veas a
alguien intentando ser el superhéroe multitarea, recuerda al director ciclista
entregando bidones mientras serpentea entre la multitud. Y pregúntate:
¿realmente queremos esperar al choque para cambiar?
O
de cómo aplicar “Las pequeñas leyes de la vida” a cambios ágiles, digitales y
con IA
El despliegue de software en horarios no aptos para personas
Para saber qué y cómo cambiar hay que conocer y entender lo
que nunca cambia. Ese es el punto de partida. Nos obsesionamos con anticipar el
futuro, con seguir la última moda tecnológica o el marco de trabajo recién
publicado. Pero rara vez nos detenemos a mirar lo que permanece, lo que
resiste, lo que no se mueve, aunque el mundo gire más rápido. Yo suelo decir
que estoy en el oficio del cambio organizacional. Pero, en el fondo, lo que he
hecho es aprender cada día a escuchar lo que no cambia en las personas, en los
equipos y en las organizaciones, y usarlo como ancla para que el cambio sea
posible.
El libro “Lo que nunca cambia” de Morgan Housel me recordó,
con anécdotas simples, que las pequeñas leyes de la vida gobiernan más de lo
que pensamos. Lo menciono porque he visto que eso mismo ocurre en las
transformaciones empresariales: cambian las herramientas, cambian los
discursos, cambian los consultores. Pero lo humano sigue ahí, con sus miedos,
sus deseos y sus incentivos. Y si olvidamos eso, lo digital y lo ágil y, más recientemente,
la IA se vuelven maquillaje pasajero.
Dejé de desarrollar software hace más de dos décadas, pero
los problemas más frecuentes en tecnología de entonces venían de desplegar
sistemas en unos días y en unas horas inverosímiles, como un viernes por la
tarde o un domingo a las 5 a. m. Hoy, con nubes más rápidas y metodologías más
sofisticadas, la historia se repite: seguimos sufriendo por desplegar en esas
fechas y horarios inauditos para nuestra humanidad. Cambian los escenarios,
pero no cambian los patrones. Lo que nunca cambia es más fuerte que lo que
creemos controlar.
Por eso he convertido esto de entender lo que nunca cambia
en un mantra y en las empresas donde he logrado que esto se acepte como una realidad,
el cambio organizacional dejó de ser una carrera por inventar lo que sigue y se
convirtió en un ejercicio de diseñar con base en lo que siempre estará ahí. Una
empresa que entiende sus constantes humanas no necesita adivinar el futuro,
porque sabe que, pase lo que pase, la gente buscará seguridad, autonomía, reconocimiento,
sentido y progreso.
Leyes pequeñas que sostienen cambios grandes
Antes de hablar de prácticas, te conviene aceptar algo: las
grandes transformaciones no se sostienen en estrategias grandilocuentes, mucho
menos en presentaciones coloridas ante la alta dirección, sino en leyes
pequeñas que se cumplen día tras día. He estado en ambos extremos. No se trata
de discursos inspiradores un jueves por la mañana que olvidamos al lunes
siguiente, sino de verdades sencillas que marcan el pulso de cualquier cambio.
Son esas pequeñas leyes las que me sirven de brújula cada vez que acompaño a
una organización. Cuando logro que sean visibles, todo lo demás fluye con más
naturalidad.
La gente sigue siendo gente. No sirve de mucho pedir
mentalidad ágil si el sistema invita a trabajar de forma lenta y burocrática.
Es más fácil que las personas cambien cuando el entorno les facilita hacerlo.
Si trabajar de manera ágil reduce esfuerzo, reduce conflictos y mejora resultados,
entonces lo ágil será la primera opción, no un discurso motivacional.
El riesgo que derrumba no siempre se ve. He trabajado
en cinco décadas distintas. Y, a propósito de lo que nunca cambia, he visto que
los grandes problemas rara vez vienen de una falla monumental y visible. Llegan
como una suma de descuidos: una alerta silenciada, un proceso sin dueño, una
validación ignorada. Con inteligencia artificial es lo mismo, basta un pequeño
error en la formulación de un pedido para que el sistema alucine respuestas y
cause daños serios. La prevención está en mirar donde casi nunca se mira.
Lo que se acumula, pesa. Las mejoras pequeñas, hechas
con constancia, transforman una organización. Los descuidos pequeños, tolerados
por costumbre, también lo hacen. Nada crece en línea recta: todo se compone y
se multiplica. De ahí la importancia de medir ritmos, no promedios. De tratar
la transformación como un jardín que necesita riego, poda y paciencia.
Las historias mandan más que los números. Un comité
puede ignorar un análisis financiero impecable, pero no puede resistirse a la
historia de una persona enfrentando a diario la misma frustración. Los números
convencen, pero las historias movilizan. Cada transformación necesita relatos
breves, claros, capaces de mostrar quién se beneficia y cómo se siente cuando
algo mejora.
Un colega me contó hace poco que un comité le negó
presupuesto para mejorar un sistema, porque en las cifras no veían retorno. Un
mes después volvió con un video: una agente de soporte repitiendo la misma
acción manual cuarenta veces al día. La petición era la misma, pero la historia
distinta. Y esta vez, aprobaron de inmediato. He estado allí.
Crecer antes de tiempo reduce lo que importa. Nada
destruye más un proyecto que escalarlo demasiado pronto. Lo aprendimos con
sangre tratando de “escalar ágil” y lo estamos repitiendo con IA generativa:
lanzar una solución inmadura a toda la organización puede ser un suicidio. El
cambio responsable necesita ensayos pequeños, pilotos controlados, pruebas que
permitan aprender sin arrasar con la confianza. Y todo ello toma tiempo.
Las cicatrices gobiernan el presupuesto. Una
organización que ha sufrido un susto fuerte nunca vuelve a ser la misma. La
memoria emocional pesa más que cualquier discurso. No sirve tratar de borrarla:
hay que diseñar con ella. Crear espacios seguros para probar, compromisos
reversibles y planes de contingencia que devuelvan tranquilidad.
Construir sobre lo que no cambia. Este es el quid de
la cuestión.Los clientes siempre querrán rapidez, claridad, precio
justo y confianza. Los empleados siempre buscarán autonomía, maestría y
propósito. Invertir en estas constantes es más poderoso que perseguir modas
pasajeras. La agilidad pasará, pero la colaboración, la entrega temprana y
frecuente, la reflexión y la mejora continua se quedan. Los modelos de IA
pasarán, pero los datos limpios, la transparencia y la seguridad se quedan.
La variación da fuerza. Nadie sabe cuál experimento
será el ganador. La única estrategia sensata es probar mucho, a bajo costo, y
cerrar rápido lo que no funciona. Esparcir semillas y preparar el suelo:
algunas no crecerán, otras se convertirán en árboles.
Preguntar siempre: ¿y luego qué? Cada decisión trae
consecuencias directas e indirectas. Lo sabemos de sobra: un bot puede reducir
a la mitad el tiempo de respuesta, pero aumentar las llamadas repetidas porque
las respuestas son incompletas. Antes de celebrar un resultado, hay que
preguntarse qué efecto oculto vendrá después.
Un mapa para sostener transformaciones
Una transformación real no depende de planes perfectos. Se
construye con equipos enfocados, con ritmos cortos y sostenibles, con datos que
muestran la realidad completa, con reglas pocas y claras. Se construye midiendo
lo esencial y aceptando que fallar barato es mejor que acertar tarde. Y, sobre
todo, se construye diseñando para lo que nunca cambia.
Para mí, un mapa de transformación comienza con algo
sencillo: definir con claridad el propósito, y narrarlo en palabras que
cualquiera en la organización pueda repetir sin confundirse. Luego, dar a los
equipos foco y autonomía real, con límites claros que eviten la dispersión.
Después, sincronizar ritmos, cadencias y compromisos, de forma que la empresa
respire al mismo tiempo y no como un conjunto de islas.
Ese mapa también incluye algo más profundo: una manera
distinta de gobernar. No con controles asfixiantes ni con promesas grandiosas,
sino con reglas mínimas, con decisiones rápidas en lo reversible y con más
cuidado en lo que deja cicatrices. Y, por encima de todo, con incentivos
alineados: porque si los premios contradicen los discursos, la cultura se
convierte en hipocresía.
Y hoy por hoy, un mapa de transformación necesita la
humildad de los líderes para aceptar que la inteligencia artificial es
herramienta y no tótem. Muy poderosa, pero herramienta, al fin y al cabo. Sirve
para aliviar dolores y multiplicar capacidades, pero no para tapar vacíos de
liderazgo ni excusar la falta de estrategia. La IA es poderosa cuando se usa
con datos confiables, con transparencia y con límites claros.
Mi llamado a la acción
Yo no creo que las organizaciones sobrevivan por adivinar lo
que viene. Creo que sobreviven porque responden mejor cuando lo inesperado
golpea. Cambiar con rapidez es valioso, pero diseñar sobre lo que nunca cambia
es lo que sostiene. Ese es el verdadero oficio del cambio: aprender a escuchar
lo que no se mueve, y desde ahí, moverse mejor.
Así que mi invitación es simple: miren de frente a sus
constantes, háganlas visibles, conviértanlas en cimiento. Y luego, construyan
cambios encima, sabiendo que, pase lo que pase, hay un suelo firme que no se
derrumba. Ese es el cambio que vale la pena.
Es definitivo: el cambio nos excita, lo constante nos
sostiene. Quien diseña solo para lo primero vuela; quien diseña también para lo
segundo aterriza.
Alguna vez fue el niño mimado. El chico dorado de la
agilidad. El marco de trabajo que prometía orden en el caos, foco en el cliente
y resultados rápidos. Pero hoy, en muchas organizaciones, Scrum es el culpable
favorito. El chivo expiatorio. El "chico malo" al que todos miran con
desconfianza cuando las cosas no salen como se esperaban.
En las comunidades de practicantes ágiles y en los foros de
discusión se le “tira toda el agua
sucia”, se refieren a Scrum como la mayor estafa metodológica de la historia
del desarrollo de software. Se habla de que no solo secuestró el concepto de
agilidad, sino que lo violó, lo desfiguró y nos lo devolvió como un frankenstein
metodológico que ni siquiera sus creadores reconocerían.
¿Qué pasó?
Scrum nació con buenas intenciones. Como ese nuevo
colaborador que llega con ideas frescas, ganas de trabajar en equipo y una
pasión por mejorar. Su estructura es simple: responsabilidades claras, eventos bien
definidos, entregables tangibles. Parece el recetario ideal para una buena
cocina organizacional.
Pero, como con cualquier receta, si los ingredientes son
malos, si el chef improvisa o si los comensales no tienen hambre de cambio, el
plato no sale bien. Scrum, por sí solo, no es una solución mágica. Y allí es
donde empiezan los problemas.
"Scrum no sirve"... ¿seguro?
"Scrum no sirve aquí", dicen algunos gerentes.
"Lo intentamos y no funcionó", dicen los equipos. Pero lo que muchas
veces no se dice es que:
Nunca
hubo un Product Owner real, con poder de decisión. O era un gerente
de proyecto enmascarado y con mucho poder. O simplemente era un ilustre
sin presencia.
El
Scrum Master era otro tipo de jefe de proyecto disfrazado. Ni hablar de
las empresas donde por decreto, de un día para otro, sin mayor preámbulo,
nombraban SM a todos los PM.
El
equipo tenía que seguir haciendo mantenimiento, soporte, incidentes y
proyectos a la vez.
Las
retrospectivas eran reuniones de quejas sin acción.
Las
revisiones de sprint eran presentaciones de PowerPoint sobre el “estado”
del proyecto.
El product
backlog era una lista de tareas heredadas, no un producto con visión.
Y esas son algunas de las cosas visibles que puedo contar sin
que me caigan encima los absurdos de los acuerdos de confidencialidad. Pero la
conclusión de todo ello sí es inevitable: como industria, elegimos la comodidad
de las recetas sobre la dureza del pensamiento crítico, preferimos comprar
certificaciones que desarrollar criterio, optamos por seguir mapas en lugar de
aprender a navegar.
Lo diré de otra manera: aplicamos un Scrum “de teatro”.
Un simulacro. Como cuando se instala un software de contabilidad pero nadie
registra los gastos. El marco estaba, pero no la intención ni la disciplina.
Predominaron nuestros egos, nuestra resistencia al cambio, nuestra incapacidad
para colaborar genuinamente. Scrum simplemente expuso nuestras heridas más
profundas y, en lugar de sanarlas, las infectamos con más burocracia disfrazada
de agilidad.
¿Falló Scrum o fallamos nosotros? O la traición del
factor humano
Scrum no falló. Lo que falló fue la implementación, la
interpretación y, muchas veces, la cultura. Implementar Scrum sin entender su
filosofía es como comprarse una bicicleta de montaña para ir a la oficina con
tacones o corbata. No es que la bicicleta sea mala. Está mal usada.
Scrum exige compromiso, transparencia, inspección y
adaptación. Y eso duele. Duele para los que prefieren el control jerárquico.
Duele para quienes temen la retroalimentaciónreal. Duele para quienes
quieren resultados sin cambiar comportamientos. Duele para quienes quieren
seguir usando Jira como si fuera una máquina de crear agilidad. Duele para
quienes convirtieron las reuniones diarias en reportes de estado glorificados.
Muchas empresas cayeron en la trampa de "agilizar"
sin transformar. Adoptaron Scrum como si fuera una nueva metodología, no un
nuevo paradigma. Siguieron funcionando igual, solo que ahora con "Daily",
"Sprint Review" y post-its de colores. Pero el miedo al error
seguía. Y el castigo al fracaso. Y la falta de visión de producto.
¿Y entonces, cómo hacer que Scrum funcione?
Con el tiempo aprendí que no se trata de "aplicar
Scrum". Se trata de vivirlo. De entender sus principios y
adaptarlos con madurez. No te voy a dar soluciones inentendibles de
consultoría, te dejaré algunas claves prácticas, cosas que puedes empezar a
hacer ya mismo si tienes la convicción, la entereza y, claro, la autoridad para
hacerlo:
Ten
un verdadero Product Owner: Con foco, con visión, con capacidad
de decir "no". Sin eso, el backlog es solo una lista de deseos
sin rumbo.
Empodera
al equipo: Scrum no es para robots ejecutores. Es para equipos que
piensan, deciden, construyen. Deja que respiren.
Invierte
en un Scrum Master real: No un jefe encubierto, ni un facilitador que
toma notas. Un verdadero agente de cambio que desafíe al status quo.
Haz
del Sprint Review un momento de verdad: Invita al cliente. Muestra
avances. Recoge feedback real. No te escondas detrás de informes.
Que
la retrospectiva no sea un ritual vacío: Cambien cosas. Experimenten.
Fallar está bien si se aprende rápido.
Mide
lo que importa: No cuentes historias por contar. Mide valor entregado,
impacto, aprendizaje. No velocidad. No "burn down".
Haz
menos, pero mejor: La trampa de la multitarea es la asesina del
enfoque. Scrum te da ritmo. Respétalo.
Además, Scrum supone que sabes hacer bien lo que haces
usando Scrum. Practica y promulga a los cuatro vientos la excelencia técnica,
la reflexión (inspección y adaptación) y el mejoramiento continuo. No persigas la
metodología perfecta, lo que debes hacer es construir mejores equipos, mejores
culturas, mejores personas. Hemos sido como alcohólicos buscando la bebida
perfecta cuando el problema no era qué tomábamos, sino que estábamos tomando.
Mi llamado a la acción
Necesitamos entender que el método, Scrum o cualquier otro, es
solo una herramienta, no el fin en sí mismo. Prioricemos resultados sobre
rituales. Sigamos las reglas, pero aprendamos a romperlas inteligentemente.
Desarrollemos hábitos profesionales sólidos: comunicación honesta, colaboración
genuina y entrega continua de valor. Con estos hábitos, cualquier marco de
trabajo, incluyendo Scrum, funciona. Sin ellos, ni siquiera el más perfecto de
los métodos nos salvará.
Scrum no está muerto. Está evolucionando. Y necesita aliados
que entiendan que su poder no está en los eventos, sino en los principios. Scrum
se convirtió en el "chico malo" porque lo empujamos a ese papel.
Porque lo implementamos sin convicción. Porque quisimos que resolviera
problemas que en realidad eran culturales, no metodológicos. Dejemos de usarlo
como escudo y empecemos a usarlo como espejo.
El fracaso de muchas personas, equipos y organizaciones con
Scrum no fue técnico, fue emocional. No entendimos que la agilidad no era una
herramienta, era un espejo. Y muchos no estaban listos para mirarse. ¿Lo estás?
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.
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.
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.
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:
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
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:
Confundir resultados clave con tareas: Un resultado clave debe ser un cambio observable y cuantificable, no simplemente la ejecución de una acción.
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.
Usar solo encuestas para medir madurez: Combina percepciones subjetivas con datos y evidencias objetivas.
Definir KPI sin una línea base: Sin un punto de partida, es imposible saber si estamos avanzando o retrocediendo.
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ō (忍道)".
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.
