No son bitcoins: la agilidad no es tolerar volatilidad, es comprar opciones baratas

Circula una metáfora atractiva en presentaciones sobre transformación: las iniciativas ágiles “son bitcoins, no letras del tesoro”. Es memorable y comunica algo cierto —que la incertidumbre es alta y los retornos son dispares— pero es conceptualmente imprecisa de una forma que produce malas decisiones.

El problema es lo que sugiere. Que agilidad significa aceptar alta volatilidad. Que hay que apostar fuerte y aguantar. Que el retorno viene de tolerar oscilaciones grandes.

Esa lectura invita exactamente al comportamiento opuesto al que produce resultados bajo incertidumbre: compromisos grandes tomados temprano, cuando la información es mínima, sostenidos por convicción en vez de por evidencia.

La formulación correcta: opciones reales

Hay un marco financiero que describe mucho mejor lo que hace una organización que navega incertidumbre con habilidad: las opciones reales.

Una opción da el derecho, pero no la obligación, de hacer algo en el futuro. Su valor tiene una propiedad específica: la pérdida está acotada al costo de la opción, mientras que la ganancia potencial no lo está. No se compra una opción para tolerar volatilidad. Se compra para participar del resultado favorable limitando la exposición al desfavorable.

Traducido a decisiones de portafolio, eso da cinco principios operativos:

Apuestas pequeñas. El tamaño inicial de cada iniciativa se define por lo que la organización está dispuesta a perder, no por lo que espera ganar.

Pérdida máxima explícita. Antes de empezar, alguien escribe cuánto se está arriesgando. Sin ese número, la decisión de detener nunca tiene un disparador claro.

Evidencia temprana. La apuesta se diseña para producir información rápido, no para llegar lejos rápido. Un experimento que en tres semanas dice si la premisa central se sostiene vale más que un desarrollo de seis meses que entrega algo completo basado en una premisa nunca probada.

Financiamiento incremental. Se libera capital por tramos, cada uno condicionado a lo aprendido en el anterior.

Expansión cuando aumenta la información. Este es el criterio que lo cambia todo: se escala una apuesta porque la incertidumbre disminuyó, no porque haya presupuesto disponible o porque el equipo esté disponible.

Lo que esto le hace a la palabra “escalar”

En la mayoría de las organizaciones, escalar significa asignar más gente. Se aprueba una iniciativa, se le asignan tres equipos, y si va bien se le asignan ocho.

Bajo la lógica de opciones reales, escalar significa algo distinto: aumentar la exposición a una apuesta cuya incertidumbre bajó lo suficiente para justificarlo.

La diferencia práctica es enorme. Bajo la primera lógica, la pregunta antes de escalar es “¿tenemos capacidad?”. Bajo la segunda, es “¿qué sabemos ahora que no sabíamos cuando empezamos?”. Y si la respuesta a esa segunda pregunta es “no mucho más”, entonces asignar ocho equipos no es escalar: es multiplicar por ocho una apuesta que sigue siendo tan incierta como al inicio, con el agravante de que ahora es mucho más costosa de revertir.

Las iniciativas de transformación fracasan por este mecanismo con una frecuencia notable. No porque la apuesta original fuera mala, sino porque se escaló antes de que la incertidumbre bajara, y para cuando la evidencia negativa llegó, había demasiada gente, demasiado compromiso público y demasiado costo hundido para detenerla.

Cómo se ve en la práctica

Una organización que opera con esta lógica hace cosas concretas y reconocibles.

Divide cada apuesta grande en tramos con criterio de continuación explícito. El tramo uno tiene un presupuesto acotado y una pregunta que responder. Si la pregunta se responde favorablemente, se libera el tramo dos. Si no, se detiene y el aprendizaje se documenta.

Define de antemano qué evidencia haría cambiar de opinión. Esto es más difícil de lo que parece y es el mejor antídoto contra el sesgo de confirmación. Si nadie puede nombrar qué resultado haría abandonar la iniciativa, la iniciativa no es una apuesta: es una convicción disfrazada de proyecto.

Trata la información como el producto principal de las primeras etapas. El primer tramo de una apuesta no entrega funcionalidad: entrega certidumbre. Y esa certidumbre tiene valor económico calculable, porque reduce el riesgo del capital que viene después.

Mantiene varias apuestas pequeñas vivas en vez de una grande. Un portafolio de opciones tiene mejor perfil de riesgo que una apuesta concentrada del mismo monto total, y produce más aprendizaje por peso invertido.

La conversación que hay que tener con finanzas

Nada de esto funciona si el área financiera espera un caso de negocio completo con proyección a tres años antes de liberar el primer peso.

La conversación con finanzas no es sobre relajar el rigor. Es sobre cambiar dónde se aplica. Un caso de negocio detallado sobre una premisa no validada tiene precisión ficticia: la mayor parte de su contenido son supuestos con dos decimales. El rigor equivalente en un modelo de opciones es distinto y bastante más exigente: pérdida máxima explícita por tramo, criterio de continuación definido antes de empezar, y revisión con evidencia real en cada punto de decisión.

Es más control, no menos. Solo que aplicado en el momento en que existe información para ejercerlo, en vez de en el momento en que no existía.

Diseñar un tramo que produzca información

El concepto se vuelve operativo en el diseño de cada tramo. Un tramo mal diseñado consume presupuesto y no reduce incertidumbre, que es la única forma de fracasar sin aprender.

Un tramo bien diseñado tiene cuatro elementos.

Una pregunta, no varias. Cuál es la incertidumbre dominante en este momento. Puede ser de demanda —¿alguien quiere esto?—, de viabilidad —¿podemos construirlo con esta arquitectura?—, de economía —¿el costo por unidad cierra?— o de adopción —¿la gente cambia su forma de trabajar?

El error frecuente es intentar responder las cuatro a la vez. El resultado es un tramo largo y caro cuyo fracaso no informa sobre cuál de las cuatro premisas falló.

El experimento más barato que la responda. Si la pregunta es de demanda, no hace falta construir el producto. Si es de viabilidad técnica, no hace falta la interfaz definitiva. La disciplina consiste en preguntarse qué es lo mínimo que produce una respuesta creíble, y aceptar que va a ser algo menos completo de lo que el equipo quisiera construir.

Un umbral definido antes. Qué resultado se considera confirmación y cuál refutación. Escrito antes de empezar, porque después de ver los datos todo resultado admite una lectura favorable.

Un límite de gasto. Cuánto se está dispuesto a perder si la respuesta es negativa. Ese número es la prima de la opción, y hace explícito lo que se está arriesgando.

Con esos cuatro elementos, un tramo de seis semanas puede reducir más incertidumbre que un desarrollo de seis meses. Y tiene una propiedad que el desarrollo largo no tiene: si la respuesta es negativa, el costo total ya se conocía de antemano y detener no requiere ninguna discusión política.

Hay un caso especial que conviene nombrar porque se maneja mal con frecuencia: cuando la incertidumbre dominante es de adopción organizacional. Ninguna prueba técnica la responde. La única evidencia válida es que un grupo real cambie su forma de trabajar durante un período suficiente y sostenga el cambio cuando deja de haber atención sobre él. Ese tramo tarda más que los demás y suele saltarse, lo que explica una parte importante de las iniciativas que funcionan técnicamente y nadie usa.

Una reformulación para tu próxima presentación

Si vas a usar una analogía financiera para hablar de agilidad, la más precisa no es la de la criptomoneda. Es esta: apuestas pequeñas, pérdida máxima explícita, evidencia temprana, financiamiento incremental y expansión solo cuando aumenta la información.

Es menos vistosa. Pero describe lo que efectivamente hacen las organizaciones que navegan bien la incertidumbre, y no invita a confundir arrojo con estrategia.