Recuerdo las primeras sesiones de formación sobre temas como integración continua o TDD, allá por 2008. También las quedadas en oficinas prestadas, en salas pequeñas, con mucha curiosidad y una sensación compartida de estar descubriendo algo que cambiaba nuestra forma de trabajar. No hablábamos de marcos de escalado, ni lo más importante era compartir las fotos de lo bien y mucho que habíamos compartido. Hablábamos de cómo dejar de sufrir proyectos eternos, cómo entregar antes, o cómo escuchar al cliente. A menudo decíamos que aquellas quedadas parecían más bien reuniones de “alcohólicos anónimos”, donde compartíamos nuestros problemas buscando el apoyo y la solidaridad del grupo. Durante años, esa conversación tuvo bastante energía. En España y Latinoamérica, organizabamos eventos —incluso conferencias—, aprendíamos de los blogs que escribíamos nosotros mismos, discutíamos sobre qué prácticas estábamos descubriendo y experimentando, con mayor o menor éxito, en nuestras respectivas organizaciones. Algunos incluso hemos llegado a vivir de ello. En definitiva, la agilidad era una conversación colectiva muy animada. 

Hoy la escena es bien distinta. La conversación existe, pero ya no ocupa el mismo lugar. No sólo porque se ha difuminado sino porque, en muchos espacios, la palabra “ágil” ya aparece poco o ni siquiera aparece. Por un lado, Agile representa una frustración para mucha gente. Promesas no cumplidas. Por otro lado, el lenguaje dominante es otro: producto, datos, inteligencia artificial, y sobre todo productividad. Un concepto que, por lo que sea, siempre ha sido prevalente en nuestra industria.

¿Un movimiento maduro, quizá acomodado?

A pesar de todo, es obligado reconocer que el entorno ha cambiado y se ha vuelto más “ágil”. Sí, has leído bien. Muchas prácticas, antes novedosas, ahora son lo normal. Iterar en fases cortas o experimentar para reducir incertidumbre se ha convertido en lo mínimo que se espera. El despliegue continuo es habitual. La infraestructura es programable. Es decir, muchas de las prácticas ágiles han tenido éxito y se han convertido en lo que cualquiera espera encontrar al entrar a trabajar en cualquier empresa que desarrolla software. Pero… la presión sobre la rentabilidad sigue siendo explícita y seguramente no hemos conseguido dar tanto como la expectativa creada. Además, la inteligencia artificial está acelerando los ciclos de producción y decisión a una velocidad tal que obliga a replantear de nuevo las prioridades estratégicas.

El agilismo introdujo una idea estructural sencilla y potente: si quieres adaptarte, necesitas prácticas y estructuras que permitan aprender con rapidez. Eso implica revisar cómo se prioriza, cómo se gestiona el riesgo y cómo se asignan recursos. Sin embargo, nuestra influencia parece haberse concentrado en el plano operativo. Equipos que trabajan mejor, ciclos más cortos, mayor visibilidad del flujo de trabajo. En grandes organizaciones, esto suele venir de la mano de varios rediseños de la organización hasta encontrar un balance entre equipos multidisciplinares y equipos más especializados. Lo que rara vez vemos es una modificación profunda del modelo presupuestario, del sistema de incentivos o de la arquitectura de autoridad. Las prácticas —en su mayoría— se han consolidado, pero la ambición estructural, no tanto. Yo diría que apenas.

Vamos a profundizar un poco más en esto último, aportando algunos datos.

Los informes globales más recientes muestran menor satisfacción declarada con Agile que hace unos años y una creciente hibridación con otros enfoques. No es que hayan desaparecido palabras como Agile, Scrum o Kanban, pero sí han dejado de servir como fórmula mágica para lograr eficiencia.

Esto no es simplemente una percepción personal. Hay datos que soportan esta observación. Por ejemplo, el State of Agile Report de 2023 mostraba una caída en la satisfacción declarada respecto a años anteriores, mientras que en el de 2025, 1 de cada 5 encuestados responden (a una pregunta parecida) que Agile se ha vuelto inútil o demasiado rígido. Pero al mismo tiempo, el ecosistema de certificaciones ha alcanzado una escala masiva. Scrum.org reporta más de un millón de profesionales certificados en sus distintos niveles y Scrum Alliance declara una comunidad superior al millón y medio de miembros. Esto habla de consolidación. También de industrialización.

Como ya he mencionado aquí en otras ocasiones, cuando he escrito sobre mapas de Wardley, la naturaleza de un movimiento cambia al entrar en fase industrial. Durante siglos, la producción de bienes se organizó en pequeños talleres, donde el conocimiento era transmitido directamente entre maestros y aprendices. Con la llegada de las fábricas durante la Revolución Industrial ese modelo cambió. La industrialización permitió producir más, con mayor consistencia y a menor coste. Pero también desplazó el foco hacia la eficiencia, la estandarización y la repetición, dejando menos espacio para el trabajo artesanal que caracterizaba a los primeros talleres.

Cuando una práctica organizativa alcanza suficiente difusión, se convierte en una oferta estructurada: cursos certificados, roles y jerarquías profesionales, servicios de consultoría replicables y, por supuesto, la enésima versión de algún framework que promete ordenar todo lo anterior. Quienes llevamos tiempo en esta industria recordaremos otras olas parecidas: certificaciones como PMP, modelos de madurez como CMMI y todo el ecosistema de auditorías, cursos y consultoras que crecían alrededor. Se gana legitimidad, escala y estabilidad, pero se pierde, en parte, capacidad crítica y fricción transformadora.

Si trasladamos esta lógica al agilismo, el efecto puede ser comparable: muchas intervenciones se concentran en el nivel operativo —mejorar la ejecución, alinear prioridades, acelerar ciclos— mientras que los cambios en la estructura organizativa, los sistemas de incentivos o la distribución de autoridad quedan con frecuencia fuera de nuestro alcance. Y eso abre una posibilidad incómoda: quizás hayamos sido tolerados porque mejorábamos la ejecución sin alterar demasiado el reparto del poder.

Si algo de esto es cierto, entonces el límite actual del agilismo no es técnico, sino político-organizativo.

¿Dónde se juega realmente la partida?

En cualquier organización, el poder no es una abstracción. Se concreta en mecanismos observables:

• Quién define las prioridades estratégicas, es decir, quién controla el presupuesto.
• Qué métricas determinan qué es el éxito y, por tanto, quién lo consigue.
• Qué estructuras de supervisión y control coordinan las dependencias entre los diferentes actores.
• Quién diseña el organigrama y, como consecuencia, quién decide cómo se distribuye la autoridad.

Así es como se decide la estrategia real: negociando, compitiendo, imponiendo…

La ventaja competitiva no se decide hoy en la mejora del delivery, sino en cómo se asigna el capital, cómo se rediseñan las capacidades y cómo se absorbe la disrupción tecnológica. Cuando un consejo de dirección decide invertir millones en una plataforma de datos o en incorporar IA en la cadena de valor, esa decisión no pasa por ningún backlog ágil. Pasa por el modelo de poder y financiación.

Me voy a poner un poco teórico. Si usamos el “Star Model” de Jay Galbraith (estrategia, estructura, procesos, recompensas y personas), la cuestión no es si Agile mejora los procesos o acelera la entrega. Eso está ampliamente documentado. La cuestión es si influye de manera coherente en el conjunto del sistema organizativo.

Según este modelo, cambiar solo la forma de trabajar de los equipos no suele ser suficiente. Si la estrategia, la estructura organizativa o los sistemas de incentivos siguen respondiendo a otra lógica, la organización termina generando fricción y los resultados de esos cambios suelen quedarse a medio camino.

En muchas organizaciones las prácticas ágiles han tenido impacto precisamente ahí, en el vértice de procesos, mientras que la estrategia, la estructura formal o los sistemas de recompensas permanecen en gran medida intactos. Los equipos iteran mejor, pero no influyen en la dirección estratégica; priorizan dentro de un marco dado, pero no redefinen los criterios de inversión; experimentan, pero sin alterar necesariamente los sistemas de incentivos que condicionan el comportamiento.

Mientras la influencia del agilismo no atraviese de forma consistente los cinco vértices del modelo —especialmente estrategia, estructura y recompensas— ni altere de manera tangible la arquitectura de autoridad en la organización (e.d. el reparto del poder), su papel quedará limitado a optimizar la ejecución dentro de marcos que otros diseñan.

No me quiero poner nostálgico, pero en su momento hubo organizaciones que sí apostaron por rediseños profundos. El caso de BBVA, ampliamente documentado —por ejemplo en la MIT Sloan Management Review o en la propia web del banco— muestra una transformación que incluyó cambios organizativos y culturales de calado. Una cuestión que creo que necesitamos responder es si esos casos marcaron una tendencia sostenida o fueron expresión de un momento concreto de transformación digital asociado a una ola tecnológica determinada.

Reabramos la conversación

Si este diagnóstico es correcto —aunque sólo sea parcialmente— la consecuencia es clara: necesitamos retomar aquella conversación colectiva y, sobre todo, elevar el nivel de la misma.

No otra discusión sobre frameworks, dinámicas de facilitación, marcos de escalado o si Scrum está bien o mal aplicado. Para eso ya tenemos muchos libros y formaciones suficientemente validadas con la práctica. Quienes llevamos tiempo en este terreno sabemos que el problema ya no está ahí.

Necesitamos examinar con rigor qué capacidad real tiene hoy el agilismo para influir en cuestiones como:

• la asignación de capital,
• el diseño organizativo,
• los sistemas de incentivos,
• el reparto de autoridad en organizaciones complejas.

Y hacerlo sin nostalgia, sin ajuste de cuentas y sin discursos identitarios.

Durante los años de expansión, la comunidad generó conversación. Aquellas quedadas, aquellos blogs, aquellos eventos improvisados funcionaban porque había curiosidad compartida y ganas de aprender unos de otros. Hoy el sector está más fragmentado y más profesionalizado. Hay más gente con experiencia, pero menos debate estructural.

Si queremos entender en qué punto estamos —y qué margen de influencia real queda— necesitamos volver a crear un espacio deliberado donde contrastar tesis, experiencias y argumentos.

Mi propuesta es sencilla: convertir agilismo.es en algo parecido a un pequeño laboratorio de ideas sobre agilidad empresarial en español. No como un proyecto cerrado ni como una agenda ya definida, sino como un espacio que podamos ir construyendo entre quienes queramos participar en esta conversación pública.

La forma puede ser la más sencilla —un blog con artículos bien argumentados— o adoptar otros formatos que tengan sentido para quienes participen. Lo importante no es el formato. Es el nivel.

Creo que lo que necesitamos son posiciones argumentadas que respondan, por ejemplo, a preguntas como éstas:

• ¿Dónde ha tenido el agilismo impacto estructural real y dónde se ha quedado en la superficie?
• ¿Qué condiciones organizativas permiten que la agilidad altere la arquitectura del poder?
• ¿Qué límites estructurales estamos evitando reconocer?
• ¿Qué papel debería jugar hoy el agilismo en un contexto dominado por IA, presión financiera y rediseño organizativo?

Sea cual sea el formato que acordemos, la condición es la misma: sostener una tesis clara, apoyarla en experiencia contrastada, datos públicos o casos documentados, y estar dispuestas a revisar nuestras propias certezas si la evidencia lo exige.

No se trata de producir contenido. El propósito debería ser generar criterios que puedan influir en cómo se diseñan organizaciones, cómo se financian iniciativas y qué papel debería jugar el agilismo en el futuro. 

La invitación

Termino con una invitación abierta destinada a quienes llevamos años trabajando en estos temas —desde dentro de organizaciones o acompañando transformaciones— y tenemos una posición argumentada sobre el papel actual del agilismo.

Vosotras sabéis quiénes sois.

Os invito a que me escribais y lo hablemos. Si os apetece, contrastemos puntos de vista y decidamos juntos cómo usar agilismo.es para reabrir esta conversación pública.

Estoy aprovechando las vacaciones para poner la casa en orden. Ya sabes, para limpiar, tirar cosas inútiles,… y para hacer un poco de retrospectiva personal. He repasado lo que he escrito en el blog en 2025 y, buah, la última retrospectiva fue hace ya tres años, al cierre de 2022, en un contexto todavía muy marcado por la pandemia. Volver ahora a esos recuerdos me ha llevado a reflexionar sobre por qué escribo en el blog, así que no esperes una retrospectiva más “clásica”: revisión de cumplimiento de objetivos y compromiso público con nuevos objetivos. Eso ya no es aquí. 🙂

Escribir también tiene sus ciclos

He exportado datos de WordPress y he hecho un pequeño resumen histórico. Si miramos el gráfico, en una lectura rápida, parece que hay épocas de entusiasmo, otras de abandono y alguna que otra recaída. Pero, al cruzarlo con lo que me ha ido pasando profesionalmente, se cuenta otra historia bastante menos lineal.

Al principio, hace casi 20 años , escribía mucho porque estaba aprendiendo mucho. Escribir era, literalmente, una forma de pensar. Descubrir prácticas, probarlas, equivocarme, volver a intentarlo… todo eso pedía ser puesto por escrito. El blog funcionaba como cuaderno de campo.

En aquella época me aplicaba pocos filtros: lo importante era entender y compartir. Compartir no como exhibición, sino como forma de contrastar, de devolver al colectivo lo aprendido y ver qué resonaba y qué no. También como forma de conocer a gente interesada en lo mismo que a mí me interesaba. Curioso, viniendo de un introvertido redomado como yo.

Con el tiempo, la cosa se complica. Empiezan los contextos difíciles —en lo personal y en lo profesional—, saltos al vacío, proyectos imposibles, organizaciones complejas, decisiones con consecuencias, transformaciones que no caben en un post sin traicionar media realidad… Y aparece una fricción nueva: no todo lo que se aprende se puede contar sin simplificarlo en exceso. Y no toda simplificación merece la pena. Ahí empieza la bajada de ritmo en el blog. La reflexión no desaparece, pero escribir deja de ser un gesto inocente.

Durante esos años, la bajada no es homogénea ni continua. Hay descensos, recuperaciones parciales, intentos de volver a un ritmo que ya no encaja del todo. Desde fuera puede leerse como irregularidad o pérdida de constancia. Vivido desde dentro, es el efecto de un trabajo cada vez más intenso, más situado y menos fácilmente exportable. Mucha práctica, mucha conversación, mucha complejidad… y menos material que merezca ser publicado sin caer en fórmulas vacías.

Y, claro, en 2020 hay un gran punto de inflexión: la pandemia y, con ella, el paso casi definitivo al trabajo en remoto. Yo diría que, al menos para mí, esto resultado ser algo más que una anécdota logística: ha sido un cambio profundo en mi forma de trabajar, de relacionarme y de aprender. Los recuerdos se confunden porque todo sucede en la misma habitación, a través de la misma pantalla. Hay mucha menos conversación informal y menos espacios compartidos donde lo vivido toma cuerpo. Ese desplazamiento también pesa en lo que publico: hay menos necesidad —y menos oportunidad— de volcar el día a día, y más acumulación silenciosa de experiencia. ¿También te pasa?

Cuando la escritura reaparece con algo más de fuerza, lo hace de manera puntual y casi experimental. Hay picos que no responden tanto a una vuelta sostenida como a la exploración de formatos o ritmos distintos que ayuden a confirmar qué tiene sentido y qué no. Es un tanteo más que un regreso pleno.

Ese tanteo no se da sólo en el formato, sino también en los espacios donde compartir. Este año he estado completamente fuera de Twitter —ahora conocido como “ese otro lugar”—, pero esto no me ha hecho especialmente más activo en LinkedIn. Sí he ido encontrando, en cambio, que Bluesky es un entorno distinto: menos activo, quizá, pero más amable. Y esa amabilidad —menos ruido, menos agresividad— se agradece cuando lo que se quiere es pensar y contrastar, no competir por atención.

Con el tiempo, no se consolida un ritmo, sino un criterio distinto. Publico en bloques, en momentos concretos donde se juntan la oportunidad y la necesidad de ordenar lo vivido. La escritura ya no aparece por obligación, sino cuando empieza a pedir ser pensada en voz alta.

El blog ya no acompaña la práctica: la decanta

Esta frase marca bien el punto en el que estoy ahora. Durante años, escribir fue una forma de pensar mientras hacía. Hoy escribir aparece cuando algo ya ha sedimentado lo suficiente como para resistir una mirada más lenta. La escritura ya no busca explicar lo que hago, sino entender qué queda cuando se aparta el ruido del día a día.

Esto tiene consecuencias. Una de ellas es que el lugar desde el que escribo ya no coincide exactamente con el lugar desde el que trabajo. La práctica sigue siendo intensa, muy dependiente del contexto, llena de fricciones y contradicciones reales; pero lo que llega al texto es otra cosa: lo que sobrevive después de pasar por varios contextos, varios intentos fallidos y unas cuantas conversaciones difíciles. Lo que resiste la tentación de convertirse en receta.

Con este cambio de foco cambian también las preguntas que me hago. Dejan de girar en torno al “cómo hacer X” y pasan a centrarse en “qué estoy dando por supuesto cuando hago X”. El interés ya no está tanto en los métodos como en las condiciones que los hacen funcionar —o los vuelven inútiles o incluso dañinos—. Más que buscar respuestas, pongo la atención en las preguntas que estructuran los problemas. Las respuestas siguen siendo necesarias, pero muchas empiezan a parecerme insuficientes para generar aprendizaje nuevo.

Por qué estos temas importan ahora

En este sentido, el blog se ha convertido en un espacio para tomar distancia de la práctica y detectar patrones que se repiten, más que para documentar lo que ocurre en tiempo real. Así, los temas de los últimos meses, algunos responden a una deuda pendiente. Llevaba tiempo trabajando con enfoques como Flight Levels o Team Topologies y necesitaba ponerlos por escrito, no tanto para explicarlos como para cumplir con ellos, para cerrar un ciclo de aprendizaje que había quedado abierto.

Otros aparecen porque necesito esos conceptos para poder seguir avanzando en los temas que ahora mismo me interesan. Wardley Mapping es un ejemplo claro: escribir sobre ello ha sido una forma de ordenar el pensamiento, de afinar el lenguaje y de construir una base común desde la que seguir explorando.

Y otros textos, sencillamente, aparecen porque sí. Porque algo pide ser pensado y compartido, aunque la motivación no esté del todo clara desde el principio.

Dicho esto, hay un hilo común que creo que atraviesa todos ellos: la necesidad de encontrar “las preguntas que NO nos hacemos”. Hemos normalizado marcos, prácticas y lenguajes que facilitan la ejecución de una manera “más ágil”, pero que al mismo tiempo reducen nuestra capacidad para cuestionar el sistema en el que operamos. Ya no me atraen ideas novedosas: creo que hay mucho conocimiento aún por articular, contrastar y aplicar a la práctica real. Pero no me interesan tanto los resultados (que también), sino los efectos de segundo orden: cómo se condiciona la toma de decisiones, qué se puede cuestionar y qué queda fuera de las conversaciones —vamos, cómo se reparte el poder—, qué tipo de aprendizaje se fomenta y cuál se bloquea… Son asuntos estructurales e ignorarlos no los hace desaparecer.

Cierre

Mirando hacia atrás (al fin y al cabo, esto pretende ser una retrospectiva), tengo la impresión de que esas tensiones que atraviesan mis artículos no son nuevas: aparecen una y otra vez en organizaciones distintas, aunque adopten disfraces diferentes. No sé:

• la dificultad para tomar decisiones en sistemas complejos,
• el uso de fórmulas y marcos de trabajo como sustituto del criterio,
• la confusión entre agilidad como capacidad y agilidad como infraestructura,
• la tendencia a optimizar localmente sin comprender el sistema que se está optimizando,
• etc.

Lo nuevo, quizá, es lo poco que las discutimos en público. Como si la comodidad de los marcos mentales hegemónicos hubiera ido ganando terreno al esfuerzo por cuestionarlos.

Puede que escribir desde aquí tenga un coste. Escribir menos implica estar menos presente en esta economía de la atención. Hacer preguntas no atrae tanto como ofrecer respuestas. No es bueno para el negocio. Asumo ese riesgo. Me resulta cada vez más difícil hacerlo desde otro lugar sin sentir que contribuyo a simplificar problemas que no lo son.

LA FOTO: Durante mucho tiempo, escribir en el blog fue casi un reflejo automático de la práctica: pasaban cosas, las contaba. Ahora no. Ahora necesito distancia, tiempo y silencio para que lo vivido se ordene un poco antes de ponerlo por escrito. El cuaderno en blanco encaja con eso. Además, el cuaderno está abierto, no cerrado. No es un diario íntimo: es una invitación a mirar, a leer, a pensar juntos.

Foto de Kelly Sikkema en Unsplash

En la primera parte del taller vimos cómo dibujar un mapa y situar sus componentes. En esta segunda entrega vamos a dar un paso más: entender qué significa que algo evolucione en el mapa y por qué eso es clave para anticipar movimientos estratégicos. A partir de aquí, un mapa de Wardley deja de ser un dibujo estático y empieza a ayudarnos a decidir qué hacer, cuándo y por qué.

notación visual: evolución de un componente

El siguiente ejercicio de nuestro taller comenzó explicando la notación que empleamos en los mapas de Wardley para indicar la evolución prevista o deseada de un componente. La línea roja punteada representa una hipótesis de futuro, es decir, algo que no está ocurriendo aún, pero que es plausible y relevante para nuestra estrategia.

Esta imagen representa la oportunidad de realizar la migración de una infraestructura física (p.ej. un centro de datos) hacia un modelo IaaS (p.ej. en AWS). Es una decisión que seguramente estaremos tomando porque queremos reemplazar activos propios por un servicio de mercado, liberando así los recursos destinados a cambio de la inversión a efectuar. Sin embargo, es importante entender que no dice “vamos a migrar”, sino “si el entorno evoluciona como esperamos, la infraestructura física tenderá a convertirse en un servicio IaaS”. Esa hipótesis es estratégicamente significativa: la organización deberá decidir si actúa como seguidora (dejando que el cambio ocurra) o como protagonista (acelerándolo mediante un movimiento estratégico).

un patrón climático: todo evoluciona

Antes de continuar, necesito que recordemos brevemente los cuatro estados de evolución en un mapa de Wardley:

• Génesis: Cuando algo apenas empieza a existir; predomina la exploración, la intuición y una gran incertidumbre.
  p.ej. una nueva idea de funcionalidad basada en IA, o un prototipo para validar la experiencia de usuario.
• A medida: Aparecen las primeras soluciones creadas específicamente; suelen ser costosas, lentas de desarrollar y poco fiables.
  p.ej. un microservicio construido sólo para un caso concreto, o una herramienta interna desarrollada rápidamente para un uso temporal de un equipo.
• Producto (o alquiler): La oferta se estandariza; surgen opciones comparables entre sí y aumenta la competencia.
  p.ej. un ordenador portátil que compras (o alquilas), o un paquete de software para el que adquieres una licencia de uso.
• Commodity (o utilidad): Hablamos de commodities (o bienes básicos) cuando son tan comunes en el mercado, tan estandarizados y predecibles en su producción, que los consideramos intercambiables entre proveedores, y lo que nos importa de ellos son el precio, la fiabilidad o la disponibilidad. Igualmente, hablamos de utilities (o servicios básicos) cuando son ofrecidos de forma continua y escalable, y se consumen bajo demanda. En ambos casos, ya no son elementos diferenciadores para nuestro modelo de negocio y pasamos a considerarlos simplemente un elemento más de nuestra infraestructura.
  p.ej. servicios de infraestructura como la electricidad, el agua corriente, o incluso servicios de computación en la nube.

Uno de los errores más comunes al leer un mapa de Wardley es pensar que la evolución de los componentes es opcional, o que sólo ocurre cuando nosotros decidimos que ocurra. Nada más lejos de la realidad. En los mapas de Wardley, todo componente evoluciona. Siempre. Este desplazamiento hacia la derecha no lo controla la organización; lo impulsa la competencia, la madurez tecnológica y la presión del mercado. Desde su génesis hasta su “comoditización” (permíteme la palabrota), todo avanza hacia la derecha del mapa. Más rápido o más lento, lo único que varía es la velocidad del movimiento. Así, la verdadera estrategia consiste en entender dónde está cada componente y decidir cuándo actuar.

En Wardley Mapping, a estas fuerzas que influyen en el paisaje competitivo las conocemos como patrones climáticos. Nosotros tenemos muy escasa influencia sobre cuándo llega el verano o el invierno, pero conocer la sucesión de las estaciones nos sirve para organizar mejor nuestras actividades. De igual forma, las organizaciones tienen muy escasa influencia sobre los efectos de los patrones climáticos, pero conocerlos nos permiten anticipar los cambios y tendencias que inexorablemente sucederán.

ejercicio #3 – posibles mejoras

Con estas ideas en mente, pedí a los asistentes del taller que identificaran evoluciones esperables en la cadena de valor de nuestra cafetería y que sugirieran acciones que podríamos hacer para aprovecharlas. Les animé a debatir entre ellos y, pasados unos minutos, les mostré una diapositiva con el presupuesto que habíamos trabajado en el ejercicio anterior. Era un recordatorio para que tuvieran en mente que quizás no todo lo que se les estaba ocurriendo sería factible. Finalmente, les compartí esta diapositiva con algunas ideas para animar el debate y contrastar con las que habían aportado ellos.

Voy a hacer un breve repaso para que te puedas hacer una mejor idea.

1. Externalizar el uso del lavavajillas aprovechando la aparición de un hipotético servicio de lavado que se encargaría de llevarse las tazas sucias y reemplazarlas una vez lavadas. De esta manera, los costes de agua, jabón, electricidad, tiempo, espacio, mantenimiento, reparaciones, amortización de la adquisición —si es que lo compramos—, etc. se transforman en el pago de una tarifa por uso.
2. El paso de tazas reutilizables (las de cerámica que nos obligan a tener un lavavajillas en nuestra cadena de valor) a tazas desechables es otra acción a considerar. Claro, habría que comparar el impacto ecológico de esta alternativa, teniendo en cuenta que nos permitiría prescindir de todo ese consumo necesario para fabricar y usar el lavavajillas.
3. Otra acción posible consistiría en fusionar los puestos de camarero y barista. La misma persona que sirve las mesas se encargaría de preparar los cafés. Si nuestra cafetería tiene pocos clientes, quizás es una opción, si no, habría que estudiar de qué manera organizamos el trabajo.
4. Una campaña de marketing haría que la cafetería fuera más popular. En el mapa verás que lo hemos dibujado con una flecha hacia arriba indicando que vemos viable que el local sea más visible de lo que lo percibe los usuarios actualmente. (Esto no es algo que haya visto en mapas más “ortodoxos”, pero creo que puede ayudar a dar más énfasis a lo que queremos transmitir).
5. Y finalmente, quizás la acción más obvia: pasar de un modelo de negocio que se basa en un local singular, con una personalidad propia, a algo con una estética y unos procedimientos estandarizados. Es lo que típicamente hacen las franquicias y que les permiten expandirse rápidamente y de manera controlada.

Cada decisión tiene sus pros y sus contras, y aún habría que aportar más detalles y debate para estar en condiciones de escoger un rumbo definitivo. Aun así, el propósito de este ejercicio no consiste en elegir qué vamos a hacer, sino en dar una visión general de cómo los mapas de Wardley nos permiten orientar mejor nuestras decisiones estratégicas.

movimientos estratégicos

Todas esas posibles acciones es lo que en Wardley Mapping llamamos “movimientos estratégicos”, o también gameplays, jugadas, o incluso estratagemas: pueden aparecer con distintos nombres.

En un mapa de Wardley, un movimiento estratégico es una acción deliberada que una organización decide ejecutar para influir en su entorno competitivo y obtener así una ventaja. Recuerda el ciclo de Boyd (OODA) que expliqué en un articulo anterior: anticipas para comprender la posible evolución de tu entorno competitivo, y ejecutas un movimiento estratégico en el momento que más te convenga para moldear esa evolución.

Simon Wardley reunió más de 60 tipos distintos de movimientos estratégicos. De momento lo vamos a dejar aquí. Más adelante, en otro artículo, escribiré sobre esto porque es esencial. Al fin y al cabo, una estrategia que no se convierte en acciones reales no es digna de ser llamada estrategia.

LA FOTO: Se trata de una escena del icónico Campeonato del Mundo de Ajedrez de 1972 celebrado en Reikiavik entre Bobby Fischer y Boris Spasski. El ajedrez se utiliza con frecuencia como referencia cuando se habla de estrategia porque obliga a evaluar el entorno, anticipar jugadas y tomar decisiones bajo incertidumbre. Además, cada movimiento implica gestionar recursos limitados y equilibrar objetivos a corto y largo plazo, lo que lo convierte en una metáfora sólida y ampliamente aceptada para pensar en estrategia.

Hay conceptos que se entienden mejor cuando se experimentan. Los mapas de Wardley son uno de ellos. Puedes leer artículos, ver diagramas o escuchar charlas, pero hasta que no dibujas uno y discutes sobre él, no terminas de comprender su potencia. Hace un año, en el evento Agility TRes60 2024, facilité un taller titulado “Agilidad empresarial con mapas de Wardley”. Fue una sesión para aprender practicando: sin teoría innecesaria, con papel y lápiz, y con un caso tan cotidiano como una cafetería. Este artículo recoge esa experiencia y te servirá si quieres introducir los mapas de Wardley en tu organización o usarlos para conversar de estrategia de una manera distinta.

ejercicio #0 – dibujamos el mapa low-tech

Los mapas de Wardley son una forma de representar visualmente cómo una organización crea valor y cómo éste depende de un conjunto de componentes (o capacidades) que evolucionan con el tiempo. Dibujados en un plano con dos ejes, permiten ver desde lo más visible para el cliente hasta la infraestructura que lo hace posible (eje vertical), y entender qué partes del sistema conviene innovar y cuáles estandarizar (eje horizontal). Su gran fortaleza radica en que permiten pensar estratégicamente desde el contexto real, no desde la intuición.

Ya expliqué los fundamentos en este artículo introductorio, pero aquí me interesa algo diferente: mostrar cómo se aprende de verdad a usarlos. Porque los mapas de Wardley se comprenden cuando se dibujan, se discuten y se contrastan con decisiones reales.

Aun así, en la primera actividad del taller, hicimos un repaso rápido de los conceptos básicos y del lenguaje visual de los mapas. Nada de una “chapa” de teoría, sólo lo justo para que todos pudieramos hablar el mismo idioma. E inmediatamente pedí a los participantes que copiaran en su papel (un A3 completamente en blanco) el mismo mapa que mostrábamos en pantalla: una simple cafetería.

Se trata de familiarizarse con la “herramienta”. Dibujar el mapa a mano tiene dos ventajas: primero, les ayuda a reconocer los elementos fundamentales (los ejes, el ancla, los componentes y las dependencias entre ellos); y segundo, garantiza que todos partan del mismo punto de referencia para el siguiente ejercicio, donde comenzaremos a explorar cómo se toman decisiones a partir del mapa.

ejercicio #1 – calculamos el presupuesto

Una vez todos tenían su mapa de la cafetería dibujado, llegó el momento del primer reto. Entregué a cada grupo una lista de costes e ingresos: alquiler del local, salarios, precio del café, suministros, mantenimiento de la máquina… Les pedí que elaboraran un presupuesto básico y, sobre todo, que distinguieran entre costes fijos y variables.

El ejercicio no busca precisión contable, sino provocar reflexión. Cada equipo debe distribuir esos datos entre los distintos componentes del mapa: qué parte del valor se genera en la barra, en la cocina, en los proveedores o en la infraestructura. Es sorprendente ver cómo, al hacerlo, comienzan a debatir sobre qué actividades realmente aportan valor y cuáles simplemente “sostienen” el negocio.

Tras unos minutos, les mostré la solución esperada. Pero en lugar de dar por cerrado el ejercicio, les lancé una pregunta que cambiaría el tono de la conversación:

“Sabemos cuánto cobramos por cada taza, pero… ¿cuál es la ganancia neta para nosotros, los dueños de la cafetería?”

La respuesta, claro, depende de cuántas tazas de café seamos capaces de vender. Enseguida la conversación giraría hacia otra cuestión más reveladora:

“¿Cuántas tazas necesitamos vender para empezar a ganar dinero? Y, más importante aún, ¿qué tendríamos que hacer para vender tantas?”

Aunque parece un ejercicio de contabilidad analítica (que también), lo que buscamos es otra cosa: usar los números como excusa para pensar estratégicamente. Es un momento clave, porque los participantes empiezan a conectar el mapa con decisiones reales: precios, volumen, eficiencia, diferenciación…

Por eso les dí la respuesta e hicimos una breve pausa para poner en común qué había ocurrido. En esa conversación emergieron patrones: algunos pensaban en optimizar costes, otros en aumentar ventas, y casi todos descubrieron que el mapa les ayuda a visualizar dónde tienen sentido unas decisiones u otras. Esa reflexión compartida es lo que convierte este taller en un aprendizaje colectivo y prepara al grupo para el siguiente paso.

ejercicio #2 – métodos de ejecución

En el siguiente ejercicio introduje una nueva capa de análisis: cómo ejecutamos las distintas actividades del mapa. Para ello, compartí esta diapositiva con la que explicar uno de los principios doctrinales de Wardley Mapping:

Usa los métodos adecuados

No existe un único método, enfoque o práctica de gestión que sea válido para todo.
El método debe adaptarse al grado de evolución del componente o actividad al que se aplica.

Este principio (ya escribiré en otro momento sobre qué es la doctrina en Wardley Mapping) nos recuerda algo que los agilistas sabemos bien. Fred Brooks lo resumió hace décadas con aquella frase: “No hay balas de plata”. Cada parte de una organización se encuentra en un grado distinto de evolución y, por tanto, necesita un enfoque diferente. Agile nos ayuda a explorar lo incierto, Lean a optimizar lo que ya funciona y Six Sigma a estandarizar lo que debe operar sin variaciones. La coherencia, pues, no surge de aplicar el mismo método en todas partes, sino de usar el adecuado en cada contexto.

Wardley se refiere siempre de forma bastante general a los “métodos adecuados”. Pero si observamos cómo los describe en sus ejemplos, en realidad está hablando de dos cosas a la vez: métodos de ejecución (cómo trabajamos sobre los componentes) y métodos de adquisición (cómo los incorporamos al sistema: construir, comprar o externalizar). Él los presenta de manera conjunta, pero creo que merece la pena distinguirlos para entender mejor la relación entre ambos.

• Los métodos de ejecución (Agile, Lean, Six Sigma) nos hablan de cómo gestionamos el trabajo: exploramos, optimizamos o estandarizamos según el grado de evolución del componente.
• Los métodos de adquisición, en cambio, nos hablan de cómo se materializa ese trabajo: si lo hacemos dentro de casa (build), si lo integramos desde fuera (comprado o alquilado) o si lo externalizamos a un proveedor (outsource).

Están correlacionados, pero no son lo mismo. Y es precisamente esa correlación lo que nos ayuda a inferir la posición de un componente en el mapa. Aunque en realidad es una lectura en dos direcciones: podemos deducir qué métodos aplicar viendo dónde está cada componente… y también deducir su posición observando cómo se trabaja. Lo interesante es cuando ambas cosas no encajan: ahí suele estar el aprendizaje.

Para trabajar mejor esta idea, incluí en la diapositiva del taller una categoría complementaria de análisis: las actividades que realizamos sobre los componentes —construir, evolucionar, corregir, operar—. A través de ellas podemos deducir qué método de adquisición estamos empleando.

En la diapositiva puedes ver la notación (a la izquierda) que solemos emplear al dibujar un mapa de Wardley para indicar el método de adquisición de los componentes. En la tabla, el símbolo de la casa indica que la actividad correspondiente se suele hacer en casa (con recursos propios), el aspa indica que no, y el cono es más bien una señal de advertencia para ser conscientes de que no siempre la decisión está clara. Y a la derecha se muestra el método de ejecución recomendado para cada uno.

Para entender mejor cómo los métodos de ejecución se relacionan con el grado de evolución, conviene mirar primero cómo obtenemos los componentes. No es lo mismo construir algo que comprarlo o externalizarlo: cada forma de adquisición implica actividades distintas dentro de la organización y, por tanto, métodos de ejecución distintos.

construir (build)

Cuando construimos, lo hacemos dentro de casa, con nuestros propios equipos y recursos. Esto implica que tenemos control directo sobre el componente y, normalmente, que todavía estamos explorando cómo debe ser o cómo funciona. Dado que nuestro foco está en manejar esa incertidumbre, lo importante no es la eficiencia, sino la capacidad de cambiar de rumbo sin hundir el barco. Por eso, las técnicas ágiles son las más adecuadas: iterar, probar, aprender y ajustar. Agile nos ayuda a reducir el coste del cambio, que es el principal riesgo cuando estamos construyendo algo nuevo.

comprar o alquilar (buy / rent)

Cuando compramos o alquilamos, lo que hacemos internamente es integrar y adaptar algo que ya existe. Ya no necesitamos explorar, sino que nos centramos en aprender a sacarle el máximo partido a algo más o menos estable. Aquí el foco está en mejorar el flujo de trabajo y reducir desperdicio: procesos, configuraciones, entregas. Por eso, tiene sentido usar un enfoque Lean, que se centra en aprender del uso real y eliminar todo lo que no aporta valor. Los métodos Lean (o de producción ajustada) funcionan bien cuando el producto o servicio ya está validado, pero aún podemos optimizar cómo lo usamos.

externalizar (outsource)

Y cuando externalizamos, la ejecución pasa a manos de un proveedor. Nosotros sólo definimos el estándar, supervisamos la calidad y gestionamos los contratos. La prioridad aquí no es innovar ni aprender, sino asegurar que las cosas se hacen siempre igual y con el nivel de calidad acordado. En este contexto, tiene sentido aplicar Six Sigma, que busca reducir la variabilidad y las desviaciones. Cuando un componente está tan maduro que puede externalizarse, lo que queremos es previsibilidad, no experimentación.

A partir de aquí, en el taller pasamos de la teoría a la práctica. Pedí a los participantes que aplicaran estos criterios al mapa de la cafetería: ¿qué deberíamos construir, qué podríamos comprar y qué convendría externalizar?

Ojo, no es un ejercicio mecánico, sino que requiere interpretar el contexto y, en algunos casos, tomar decisiones. Por ejemplo, si nos fijamos en la máquina de café, obviamente nosotros no la construimos, pero sí la operamos (e.d. la usamos, la limpiamos, etc), pero cómo actuamos ante las reparaciones dependerá de si la hemos comprado o alquilado, o si tenemos un seguro contratado, etc. Por cierto, en productos digitales esto es más sutil, pero conviene pensarlo: la forma de adquisición condiciona la forma de trabajar.

Cerramos la sesión poniendo en común las propuestas y comparándolas con el mapa que yo había preparado. Ese mapa nos llevaría a explorar un territorio nuevo: el de las inercias, los aceleradores y las jugadas estratégicas. Pero eso lo contaré en la siguiente entrega.

¿Te acuerdas del famoso modelo Spotify? Ése que todo el mundo ponía en sus presentaciones como si fueran cromos. No voy a decir que fuera un mal ejemplo: sirvió para que muchas empresas empezaran a pensar en equipos multidisciplinares y autónomos. El problema vino cuando se convirtió en un póster decorativo: se repetía la forma, pero se descuidaba el fondo.

Ahí es donde aparece Team Topologies. Hace un par de años ya publiqué una presentación introductoria sobre el libro, pero hoy quiero explicarte por qué los patrones de este enfoque son tan relevantes, qué problemas intentan resolver y cómo pueden realmente transformar la agilidad empresarial.

Team Topologies en pocas palabras

Este enfoque fue creado por Matthew Skelton y Manuel Pais y publicado en 2019 en el libro Team Topologies. Nació como respuesta a los problemas de escalabilidad y complejidad organizativa que muchas empresas de software sufrían, cuando modelos de referencia como el de Spotify se mostraban ineficaces para organizar equipos de forma efectiva. Su propósito es aportar un conjunto de patrones claros para abordar estos retos. De hecho, originalmente aparecen con el nombre de DevOps Topologies.

No es un framework ni una receta cerrada. Es, más bien, una forma práctica de pensar cómo organizamos nuestros equipos y cómo estos interactúan entre sí. Porque, al final, la agilidad empresarial depende de cómo fluye el valor a través de tu organización. Por cierto, quédate con este concepto —el flujo de valor— porque lo vamos a repetir hasta la saciedad.

Team Topologies propone una serie de patrones que ayudan a diseñar esas estructuras e interacciones de forma intencionada, y son los que veremos a continuación.

¿Por qué necesitamos estos patrones?

La premisa central de Team Topologies es que la forma en que organizas equipos y cómo interactúan afecta directamente a la arquitectura del producto, la velocidad de entrega y la capacidad de adaptarse al cambio. Esta idea conecta directamente con la Ley de Conway, que sostiene que “Las organizaciones están condenadas a producir sistemas que son copia de sus estructuras de comunicación”.

Si tus equipos se comunican de forma lenta, debido a silos de conocimiento y multitud de dependencias entre equipos, tus sistemas también lo reflejarán. Y al revés: si quieres una arquitectura más modular y flexible, necesitas rediseñar tus equipos para que trabajen así. A esto se le llama la maniobra inversa de Conway.

Por eso, si no definimos intencionadamente cómo se organizan los equipos (y cómo se comunican), la estructura del sistema —y el flujo de valor que la atraviesa— tenderá a reflejar las ineficiencias organizativas. Para una explicación más amplia, puedes ver mi artículo:

Aquí entra en juego otro concepto clave: la carga cognitiva. Cada equipo tiene una capacidad limitada para comprender y gestionar la complejidad de su dominio. Team Topologies toma este concepto de la teoría del aprendizaje para recordarnos que, cuando esa capacidad se desborda —porque el equipo asume demasiadas responsabilidades, dependencias o tecnologías—, la colaboración se degrada y el valor deja de fluir. Por eso, el diseño organizativo debe cuidar tanto la arquitectura del producto como la capacidad mental colectiva necesaria para sostenerla.

Los patrones de Team Topologies ayudan precisamente a equilibrar esas dos tensiones: diseñar equipos y relaciones que reflejen una arquitectura sana y que mantengan la carga cognitiva dentro de límites sostenibles.

Las 4 topologías fundamentales

Team Topologies propone cuatro tipos de equipo con roles bien diferenciados:

• Equipo orientado al flujo: Alineado con un único flujo de valor. Su trabajo se centra en un único producto o servicio, un único conjunto de funcionalidades, un único user journey o una única user persona.

El propósito del resto de topologías será reducir la carga de estos equipos alineados al flujo de cambios.

• Equipo habilitador: Ayuda a los equipos alineados al flujo a superar obstáculos y detecta capacidades faltantes. Tiene holgura para investigar, probar opciones y hacer sugerencias informadas.
• Equipo de subsistema complicado: Responsable de construir y mantener una parte del sistema que depende altamente de conocimiento muy especializado (difícilmente estandarizable o adquirido mediante una formación).
• Equipo de plataforma: Agrupación de otros tipos de equipos que proporcionan servicios internos que reducen la carga cognitiva de los equipos orientados al flujo.

Los 3 modos básicos de interacción

Sólo hay 3 modos en los que los equipos deberían interaccionar:

• Colaboración: Trabajar juntos por un período de tiempo (no indefinidamente) para explorar algo nuevo (APIs, prácticas, tecnologías, etc). → Descubrimiento rápido
• X-as-a-Service: un equipo proporciona y un equipo consume algo “como un servicio”, e.d. la solicitud está estandarizada y el resultado es predecible. → Entrega predecible
• Facilitación: Un equipo ayuda o mentoriza a otro equipo para que adquiera nuevas capacidades. → Ayuda activa

Con esta simplificación radical se consigue lo que muchas organizaciones llevan años buscando: reducir fricciones, acortar tiempos y que cada equipo sepa para qué existe, cómo se debe relacionar con los demás y cómo los demás se deben relacionar con él.

La imagen a continuación es un resumen de estos patrones con la notación empleada originalmente.

En los ejemplos que verás a continuación empleo otra notación más actual para los modos de interacción, pero el significado es el mismo.

Un ejemplo de estos patrones en acción

Imagina que una aerolínea organiza su desarrollo en torno a una aplicación móvil de reservas y gestión de vuelos, usando el modelo Team Topologies para estructurar sus equipos. Los equipos orientados al flujo de valor se encargan de entregar funcionalidades directamente a los clientes: el equipo de Reservas Online mejora continuamente la experiencia de búsqueda, compra y check-in, mientras que el equipo de Fidelización gestiona el programa de puntos y beneficios. Ambos colaboran para integrar sus servicios y ofrecer una experiencia fluida al usuario final.

El equipo habilitador de UX Research actúa de forma temporal para ayudar a los equipos de producto a adoptar prácticas avanzadas de diseño centrado en el usuario. Este acompañamiento (facilitación) se limita al tiempo necesario para que los equipos integren los nuevos aprendizajes y trabajen de forma más autónoma.

En paralelo, el equipo de subsistema complicado desarrolla el Motor de Precios, un motor de tarifas y disponibilidad que expone su funcionalidad como servicio a los equipos de producto. La plataforma digital (DXP) proporciona servicios comunes —autenticación, despliegue, observabilidad— usados por todos los equipos (X-as-a-Service), asegurando coherencia técnica y facilitando un flujo de entrega más rápido. Así, la organización combina colaboración, especialización y autonomía para sostener su agilidad a gran escala.

El resultado final: el equipo de flujo puede centrarse en entregar valor al cliente sin ahogarse en dependencias ni problemas técnicos que otros tipos de equipo resuelven mejor.

NOTA: Para crear tus propios diagramas, puedes usar Miro e instalar la herramienta “Team Topologies” pulsando en el botón para Añadir Herramientas (en el menú de la izquierda).

Por cierto, si tienes interés en aprender más sobre Team Topologies, creo que este recurso te resultará muy útil. Se trata de una plantilla Miro para un organizar un club de lectura enfocado en el libro: https://miro.com/templates/team-topologies-book-club-guide-template/

Qué cambia realmente al aplicar Team Topologies

Aplicar Team Topologies no consiste en subirse a otra moda, sino en intervenir en las entrañas del sistema para que la agilidad ocurra de verdad. No añade capas de reglas (como hacen la mayoria de marcos de trabajo), sino que reconstruye las condiciones que hacen posible que la agilidad emerja.

Siguiendo las categorías de potenciadores e inhibidores que propone Sunil Mundra:

• En la estructura organizativa, los equipos dejan de alinearse por departamentos para hacerlo alrededor de flujos de valor. Los equipos orientados al flujo sustituyen a los silos funcionales y reducen dependencias, mientras que el resto de equipos limitan la carga cognitiva y permiten que la organización se adapte sin fricción. La estructura ya no es un obstáculo: se convierte en un instrumento de aprendizaje.
• En los procesos, Team Topologies pone orden donde antes había improvisación o burocracia. Define interacciones claras entre equipos —colaborar, facilitar, proveer servicios— y convierte el trabajo en flujo continuo. El foco deja de estar en los proyectos y pasa a estar en los outcomes: entregas pequeñas, feedback rápido y aprendizaje constante.
• El cambio también se nota en las personas. La autonomía deja de ser un discurso y se vuelve tangible cuando los equipos tienen límites claros y responsabilidad de extremo a extremo. Los equipos habilitadores ayudan a otros a adquirir nuevas capacidades, reduciendo la sobrecarga y fomentando la colaboración. Con menos ruido y más claridad, la motivación deja de depender del carisma de los líderes y pasa a surgir del propio trabajo bien diseñado.
• La tecnología deja de ser un cuello de botella y se convierte en un aliado. La maniobra inversa de Conway —diseñar equipos para inducir la arquitectura deseada— permite que los sistemas evolucionen al ritmo del negocio. Las plataformas, tratadas como productos, eliminan fricciones y devuelven velocidad a los equipos de flujo.
• En cuanto a gobernanza, Team Topologies cambia el control por la confianza. Las decisiones se toman donde está el conocimiento, y la visibilidad del flujo sustituye los comités interminables. La gestión de proyectos se convierte en gobernanza por flujos: más trazabilidad del valor, menos supervisión innecesaria.
• Y, finalmente, cambia la relación con el cliente. Al tener equipos alineados con los flujos de valor, el feedback llega antes, la empatía se amplifica y la experimentación se vuelve natural. Los equipos entienden el impacto de su trabajo en la experiencia real del usuario y pueden ajustar el rumbo sin esperar a una gran revisión trimestral (como en el caso de SAFe).

Para un CxO o un responsable de transformación, la pregunta no es si aplicar Team Topologies o no, sino cuánto tardarás en darte cuenta de que la capacidad competitiva de tu organización depende de rediseñar los equipos en torno al flujo de valor.

Qué aporta la segunda edición

Acaba de salir publicada la segunda edición y no quería perder la oportunidad de mencionar qué hay de nuevo en la misma. No es una revisión menor: amplía el marco con matices que reflejan lo aprendido tras años de aplicación en organizaciones de todo tipo.

La principal novedad es la aclaración sobre el concepto de plataforma. Los autores precisan (también aquí) que un equipo de plataforma no siempre es un único equipo, sino que puede tratarse de un agrupamiento de equipos (platform grouping) que, en conjunto, ofrece los servicios necesarios a los equipos de flujo. Esta ampliación da lugar a la idea de value stream grouping y subraya lo que ellos llaman la naturaleza fractal de las organizaciones: patrones que se repiten a distintos niveles de escala, desde un equipo hasta un ecosistema completo de plataformas.

La segunda aportación importante es un anexo de casos reales, que documenta experiencias concretas de aplicación de Team Topologies en empresas y administraciones públicas. Más que ejemplos de éxito, son referencias bastante valiosas para entender cómo se adapta el modelo sin perder su esencia.

Y finalmente también tenemos un epílogo en el que los autores miran hacia el futuro con optimismo. Así, celebran que sus ideas hayan ayudado a construir organizaciones más humanas y efectivas, y destacan la conexión con otros marcos complementarios como Wardley Mapping o Domain-Driven Design. Además, la carga cognitiva ocupa ahora un lugar aún más central: cuando los equipos trabajan dentro de límites saludables, esto permite que la calidad, la innovación y la simplicidad florezcan. Frente a la tentación de automatizarlo todo, los autores insisten en usar la tecnología (las IAs) para ampliar las capacidades humanas, no para sustituirlas.

Si quieres ver cómo estas ideas se están materializando en organizaciones reales, puedes echar un vistazo a la charla Emerging Patterns & Anti-Patterns with Team Topologies, donde los propios autores comparten aprendizajes recientes y los retos que están emergiendo al escalar el modelo.

Repensar la agilidad desde la estructura

A veces confundimos la agilidad con moverse rápido, cuando en realidad se trata de moverse con sentido. Team Topologies nos recuerda que la agilidad no nace de los rituales ni de las etiquetas, sino de una estructura que permite a las personas concentrarse en lo que importa.

Cada vez que un equipo se ve atrapado en dependencias, en burocracia o en métricas vacías, el sistema nos está diciendo algo: que la organización necesita rediseñarse para liberar su propio potencial. No hay transformación posible si la estructura sigue jugando en contra. En ese sentido, Team Topologies no es sólo un modelo de organización de equipos, sino una invitación a mirar la agilidad desde sus cimientos y a preguntarnos no “qué framework necesitamos”, sino “qué impedimentos estamos diseñando”.

FOTO: Como sabes, me gustan mucho emplear metáforas para entender mejor los conceptos. Esta foto de Acton Crawford en Unsplash sirve para ilustrar los principales conceptos de un diseño organizacional basado en Team Topologies.

Vista desde arriba, una organización que funciona bien se parece mucho a una estación de trenes. Cada convoy avanza por su carril entregando valor —como los equipos alineados al flujo—, mientras otros se ocupan de tareas más técnicas o especializadas. En los márgenes, los talleres y depósitos sostienen el sistema, igual que los equipos de plataforma, y los equipos habilitadores se mueven entre vías ayudando a que todo fluya. Cada tren mantiene su rumbo porque no tiene que ocuparse de todo: la estructura está pensada para proteger su atención, reducir la carga cognitiva y dejar espacio para avanzar.

Tengo prácticamente listo un artículo sobre cómo mejorar la agilidad empresarial con Team Topologies, pero decidí posponerlo para leer la nueva edición del libro que, por cierto, ya ha salido y me está gustando. Mientras tanto, pedí ayuda a mi red en LinkedIn para escoger tema: podía hablar de desarrollo de producto, de Wardley Mapping o de qué estoy haciendo ahora. Y la opción más votada fue precisamente esta última. Así que aquí va el resultado, contado sin saltarme ninguna cláusula de confidencialidad. Espero.

No es la primera vez que trabajo para una organización grande, con muchos departamentos, roles difusos y procedimientos que no siempre encajan entre sí. Esa experiencia de años me ha enseñado a no esperar un terreno despejado, sino a ir leyendo el contexto para decidir dónde tiene sentido intervenir y dónde lo más inteligente es no estorbar. Hoy desempeño el rol de Scrum Master en un área de la compañía llamada Digital Platform, un trabajo en el que procuro combinar la cercanía —estar muy pegado a la parte operativa y también a las personas, independientemente de su rol— con una visión estratégica que favorezca la agilidad de todos.

He llegado en plena transformación

Digital Platform está en medio de una transición. Durante años, su foco principal ha consistido en sostener la infraestructura sobre la que se despliegan muchas de las aplicaciones clave de la compañía. Ahora, además, impulsa la construcción de una Digital Experience Platform (DXP), lo cual amplía el alcance mucho más allá del soporte técnico.

En este contexto conviven equipos que trabajan en la migración de páginas web desde sistemas previos hacia soluciones más modernas, otros que desarrollan un sistema de diseño, o los que coordinan despliegues y cambios críticos para que todo siga funcionando de forma segura y consistente. Puede parecer invisible desde fuera, pero el trabajo de Digital Platform evita que cientos de desarrolladores tengan que ocuparse de estas tareas de manera descoordinada, con la complejidad y el riesgo que eso supondría. Esta posición, tan transversal como estratégica, explica por qué su transformación es clave dentro de esta compañía: una gran aerolínea.

¿Qué es eso de DXP?

El concepto de Digital Experience Platform (DXP) es la respuesta a una cadena de necesidades crecientes. Al principio bastaba con los Content Management Systems (CMS), diseñados para crear y publicar páginas de manera sencilla. Pronto se vio que no era suficiente: había que personalizar contenidos, incorporar analítica y coordinar distintos canales, lo que llevó al surgimiento del Web Experience Management (WEM). Pero también WEM se quedó corto, porque las organizaciones necesitaban que todo esto estuviera conectado con sus datos, servicios y procesos internos.

De esa evolución surge el concepto de DXP: un entramado de tecnologías que no sólo gestiona contenido, sino que integra lo necesario para ofrecer experiencias digitales consistentes y personalizadas a través de los múltiples canales de la compañía. En el caso de Digital Platform, el objetivo no es adoptar un producto cerrado, sino construir su propia plataforma sobre la que se apoyen las distintas iniciativas digitales de la compañía. Esto explica por qué el área es tan transversal. En una aerolínea, la experiencia digital está en casi cada punto de contacto con el cliente: desde buscar un vuelo hasta recibir notificaciones sobre un embarque.

Mi rol

Yo no estoy implicado directamente en los detalles de lo que construyen los equipos. Mi papel no consiste en entender cada aspecto de la experiencia digital ni de la infraestructura que la soporta: eso lo saben mucho mejor los equipos especializados en cada parte de la cadena de valor. Yo sólo me centro en cómo trabajan.

En una misma semana puedo estar hablando de flujos de despliegue, revisando la planificación de un sistema de diseño o creando una automatización en Jira. Aunque los focos varían, hay un hilo conductor: los procesos. Me interesa mucho cómo se coordinan, cómo resuelven dependencias, o cómo se enfrentan a la complejidad del día a día. No me preocupa tanto qué hacen, sino cómo lo hacen. Esa perspectiva me permite moverme entre contextos muy distintos sin necesidad de convertirme en especialista de cada uno, y a la vez aportar valor ayudando a que los equipos encuentren mejores maneras de colaborar.

Aunque todo agilista dirá que lo importante son las personas y sus interacciones, yo prefiero fijar la atención en los procesos. Porque son ellos los que marcan el terreno de juego, los que facilitan o entorpecen las interacciones y, en última instancia, los que hacen posibles ciertos comportamientos y bloquean otros.

Donella Meadows lo expresó con claridad al hablar de sistemas:

Si queremos entender los fallos más graves de los sistemas, tendremos que prestar atención a las reglas y a quienes tienen poder sobre ellas.

— “Thinking in Systems” (Edición en español: “Pensar en Sistemas”, Capitán Swing)

Dejo aquí apenas la semilla. En otro artículo me meteré de lleno en este debate.

Entre irritar y acompañar

Justo debido a este enfoque, cuando llego a un nuevo entorno, lo primero que hago no es cambiar cosas, sino observar. La experiencia en empresas grandes me ha enseñado que los equipos viven bajo una maraña de dependencias y procesos heredados, y que mi papel como Scrum Master empieza por distinguir lo que es ruido de lo que es realmente un bloqueo.

Mi caja de herramientas es amplia: talleres, documentación, configuración de Jira, métricas, conversaciones incómodas… Todo lo que sé hacer lo pongo al servicio de una idea sencilla: incomodar lo justo para identificar los problemas y ofrecer alternativas viables para mejorar. Hace ya muchos años escribí sobre irritar al sistema, y aún hoy sigo practicando ese arte parecido al funambulismo: un equilibrio constante entre provocar y acompañar, entre hacer visible la incomodidad y no detener el avance. Irritar para movilizarnos, pero sin romper la cuerda por la que caminamos.

Hace años me inclinaba más por transformaciones radicales. Con el tiempo, trabajando en organizaciones grandes, he descubierto que lo más efectivo suele ser apostar por pequeños cambios que generan dinámicas positivas y que otros pueden extender al resto de la organización. Ay, el viejo debate entre kaizen y kaikaku.

Por cierto, en Reparando en vuelo describo cómo enfoco ahora la transformación de una organización cuando no hay margen para parar máquinas, aprendiendo a mejorar mientras se sigue avanzando. Ésa es la forma en la que entiendo hoy la agilidad empresarial: no como grandes gestos, sino como la capacidad de ajustar el rumbo sin detener la marcha.

Y hasta aquí por ahora

A estas alturas quizás te preguntes qué papel juego yo en todo esto. Me gusta mucho recordar que mi puesto no tiene poder, pero sí influencia: no soy jefe de nadie, y por tanto no puedo decidir qué deben hacer los demás, aunque sí aspiro a modificar mi entorno para que suceda lo que debe suceder. Para explicar esto, me gusta recurrir a una imagen sencilla: soy una especie de acompañante del grupo con una linterna en la mano. No marco la ruta; sólo alumbro lo que tenemos delante para que el equipo vea mejor dónde pisa y pueda elegir con menos miedo.

Alguna vez me han comparado con un sherpa, pero esa metáfora no me termina de encajar. Demasiada épica para mi gusto. Y la épica, en el trabajo, suele ser postureo: grandes gestos que esconden más vanidad que resultados. Yo prefiero algo más discreto. La linterna no promete hazañas, solo claridad. Y en entornos llenos de incertidumbre, ya es bastante.

Y hasta aquí este “qué estoy haciendo ahora”. Gracias por acompañarme en este recorrido. El siguiente artículo será ya el que tenía en mente sobre cómo mejorar la agilidad empresarial con Team Topologies, y después vendrá la reseña de la segunda edición del libro, que estoy disfrutando y creo que merece dedicarle espacio propio.

LA FOTO: La linterna que ilumina el camino como metáfora de mi manera de abordar mi trabajo.

Foto de Subhro Vision en Unsplash

En el agilismo nos hemos vuelto expertos en iteraciones, frameworks y equipos autoorganizados, pero cuando la conversación pasa al plano estratégico —decidir qué batallas librar y hacia dónde orientar el negocio— solemos quedarnos fuera. A veces por falta de acceso a los foros donde se toman esas decisiones, pero otras muchas porque nuestras herramientas no llegan tan lejos. Este artículo nace de esa incomodidad.

Ya compartí una primera versión de estas ideas en la CAS 2024 (en la charla titulada Agilidad empresarial con mapas de Wardley), donde explicaba cómo podemos conectar la agilidad empresarial con la dirección estratégica del negocio. Aquí quiero retomar esas ideas y desarrollarlas con más calma.

Estrategia no es táctica

Uno de los grandes males que aqueja nuestro sector es que quemamos conceptos a la velocidad del rayo. Una de esas palabras es “estrategia”. La usamos para todo: para justificar un roadmap, para ponerle un nombre importante a una iniciativa, para anunciar que un equipo tiene nuevos objetivos. A veces se etiqueta como “estrategia” cualquier planificación a medio plazo, como un roadmap o una hoja de ruta trimestral. O se utiliza para dar empaque a iniciativas que son, en realidad, decisiones tácticas o ajustes organizativos. Basta con añadir la palabra para que parezca que lo que hacemos tiene más importancia. Y este abuso nos lleva frecuentemente a confundir “estrategia” con “táctica”, y actuamos como si fueran intercambiables. Pero la estrategia tiene que ver con qué batallas eliges para adquirir una ventaja competitiva. La táctica, en cambio, es cómo libras esas batallas.

Me gusta distinguir ambos conceptos usando estas definiciones:

estrategia (f.)
Diseño y ejecución de un plan concebido para sacar la mayor ventaja posible de las condiciones y de los recursos dados.

táctica (f.)
Movimiento o acción específica, que se aplica en una situación puntual para obtener un resultado concreto.

Esta confusión tan habitual nos lleva a que, cuando llega el momento de una transformación organizativa, nos pilla sin herramientas para hablar en serio de estrategia. En lugar de preguntarnos qué queremos conseguir o por qué cambiar ahora, nos lanzamos de cabeza a lo táctico: “¿Scrum o Kanban?”, “¿Montamos squads?”, “¿Centralizamos el frontend?”. Como no sabemos movernos en el plano estratégico, nos quedamos mudos… o llenamos el silencio con decisiones técnicas, organizativas o metodológicas que suenan bien pero no responden a ninguna pregunta importante. Cambiamos cosas, sí, pero sin saber bien para qué.

El vacío de la estrategia de transformación

Si me sigues habitualmente, quizás recuerdes que ya en un artículo de 2018 mencionaba la diferencia entre estrategia del negocio (el “qué” y el “para qué” de la organización) y estrategia operativa (el “cómo” llevamos eso al día a día). Esa distinción sigue siendo clave, pero entre ambos planos hay un vacío que suele ser el terreno donde se pierden muchas transformaciones: la estrategia de transformación organizacional hacia la agilidad empresarial.

El papel de la estrategia de transformación es servir de puente entre la dirección estratégica del negocio y los cambios concretos en la organización:

• decidir qué capacidades internas conviene desarrollar,
• cómo reorganizar equipos y modelos de trabajo,
• y qué prácticas y formas de liderazgo reforzar o dejar atrás.

Su propósito es responder a cambios del entorno (mercado, tecnología, regulación) y hacerlo de manera medible y adaptable, de forma que el cambio no se quede en iniciativas puntuales sino que se convierta en una evolución sostenible de la organización.

Pero aquí topamos con un vacío: hablamos mucho de prácticas, equipos y marcos de trabajo, sin embargo apenas disponemos de recursos que nos ayuden a movernos en este plano intermedio, el de la estrategia de transformación. Nuestra caja de herramientas, aunque abundante, deja fuera precisamente lo que más necesitamos para conectar con la dirección estratégica.

Nuestra caja de herramientas está incompleta

Y no es por falta de recursos. Al contrario: cuando hablamos de transformación organizativa y agilidad empresarial, solemos llevar una caja de herramientas bastante bien equipada:

• En ingeniería del software, usamos integración continua, TDD, arquitecturas modulares y un larguísimo etcétera de buenas prácticas.
• Para la gestión del trabajo, recurrimos a Scrum, Kanban o cualquier método que nos permita inspeccionar y adaptar para la mejora continua.
• En gestión de producto, nos apoyamos en ciclos iterativos e incrementales, OKRs, design thinking y otro montón de técnicas que ayudan a no olvidarnos de los usuarios.
• En gestión de equipos, tiramos de marcos de autogestión como sociocracia, dinámicas de feedback o prácticas de colaboración que fomentan la responsabilidad compartida.
• En diseño organizacional, incorporamos modelos como Team Topologies, Flight Levels o diversos marcos de escalado que nos ayudan a dar coherencia al sistema.
• En cultura y liderazgo, manejamos enfoques que buscan impulsar el cambio desde dentro, como el liderazgo servicial, la facilitación sistémica o iniciativas de aprendizaje colectivo.

Pero cuando la conversación gira hacia el diseño de la estrategia de transformación empresarial, la caja se nos queda medio vacía. Nos faltan marcos que conecten nuestras decisiones con el posicionamiento competitivo de la organización, sus restricciones estructurales o las decisiones pasadas que ya condicionan el camino. Sin esa conexión, nuestras propuestas —por acertadas que sean— quedan en un plano operativo.

Aquí es donde entra en juego una técnica distinta: una que permite representar visualmente una cadena de valor, ver cómo evoluciona y anticipar su transformación. Se llama Wardley mapping.

Un mapa de Wardley dibuja la cadena de valor de tu organización en dos ejes: lo que el cliente percibe y valora, y cómo evolucionan los componentes de lo novedoso a lo estandarizado. Lo potente no es el gráfico en sí, sino la conversación estratégica que abre: qué necesita de verdad el cliente, de qué dependen esas necesidades, qué conviene estandarizar y dónde merece la pena poner los esfuerzos de innovación.

Y aquí es donde la cosa se pone interesante: si trabajas en mejorar la agilidad empresarial, Wardley Mapping no es un framework más, sino la pieza que falta en tu caja de herramientas para mover la conversación al plano estratégico.

Por qué Wardley mapping debería importarte

Y aquí es donde los mapas de Wardley resultan determinantes: permiten trazar un hilo común entre los tres planos de la estrategia:

• A nivel de estrategia del negocio: ¿dónde competimos?, ¿qué batallas merece la pena librar?, ¿qué capacidades necesitamos desarrollar para sostener la ventaja competitiva?
• En la estrategia de transformación: ¿cómo debe cambiar la organización para habilitar esa estrategia?, ¿qué estructuras, roles y prácticas hacen posible competir en ese escenario futuro?
• En la estrategia operativa: ¿cómo asegurarnos de que lo que hacemos cada día conecta con la estrategia de transformación y, por extensión, con la empresarial?

Si trabajas en mejorar la agilidad de tu organización, seguramente te habrás encontrado con huecos incómodos al tratar de responder varias de esas preguntas: debates que nunca llegan a nada porque falta un marco común, prioridades que se deciden sin conexión con la estrategia, equipos reorganizados sin un propósito claro más allá de “implantar un framework”. Ese es el terreno donde muchas transformaciones se pierden.

Con Wardley Mapping, esas mismas energías pueden enfocarse en lo que de verdad importa:

• decidir dónde innovar, para no gastar energía en ideas brillantes que no aportan valor real;
• saber qué conviene estandarizar o delegar, para liberar recursos de lo que ya es rutinario;
• identificar qué prácticas necesitamos mejorar o adaptar, porque lo que hoy nos funciona mañana puede quedar obsoleto;
• reforzar las capacidades clave dentro de la organización, las que nos permiten competir a largo plazo;
• elegir el momento adecuado para cada movimiento, evitando tanto la improvisación como llegar tarde;
• y distinguir cuándo colaborar y cuándo diferenciarse, para aprovechar alianzas sin perder lo que nos hace únicos.

Wardley mapping y OKRs

La dirección por objetivos —ya sea con OKRs, Hoshin Kanri u otros sistemas similares— encuentra aquí un apoyo fundamental: un mapa de Wardley permite situar cada objetivo en su contexto, mostrando de qué depende y qué aporta.

Por ejemplo, un OKR como “Aumentar la conversión en un 10%” parece claro y accionable, pero al verlo en un mapa descubrimos que centrarse en optimizar el checkout apenas moverá la aguja: hoy en día cualquiera puede integrar soluciones como Stripe, PayPal, etc, y el proceso de pago se ha convertido prácticamente en un estándar del sector. En cambio, lo que realmente puede marcar la diferencia está en la personalización de la experiencia de producto: recomendaciones como hace Netflix, o compras sugeridas como en Amazon.

Esta diferencia no es sólo táctica y puede ir directamente al backlog de un equipo: afecta directamente a las decisiones de transformación. Invertir en optimizar el checkout implica reorganizar equipos de frontend o dedicar recursos técnicos a algo que ya está resuelto por el mercado. Apostar por la personalización, en cambio, exige reforzar capacidades en analítica, diseño de producto o incluso machine learning, y posiblemente crear nuevas estructuras para sostener esa ventaja competitiva.

¿Y la dirección por misiones?

La dirección por objetivos es lo más extendido, pero no es la única manera de alinear estrategia y ejecución. Existe también la dirección por misiones, un enfoque menos conocido pero que considero muy inspirador. Encaja especialmente bien con organizaciones que aspiran a ser realmente ágiles.

Wardley mapping también puede dar soporte ahí: aporta el contexto compartido que necesitan los equipos para interpretar la misión de forma coherente y decidir cómo contribuir desde su autonomía.

(Es un tema que merece artículo aparte; mientras tanto, puedes echar un vistazo a lo que escribí hace tiempo sobre planificación estratégica orientada a misiones).

Conclusiones

Seamos sinceros, la mayoría de transformaciones ágiles se quedan en lo superficial: reorganizamos equipos, adoptamos frameworks, modernizamos tecnología… y pensamos que con eso estamos compitiendo mejor. Pero sin una conexión clara con la estrategia, esos cambios se quedan a medio camino.

El reto no es “implantar SAFe” ni “moverse a la nube”. El reto es asegurar que cada decisión táctica responde a una necesidad estratégica. Lo que me fascina de Wardley Mapping es que pone a nuestra disposición un lenguaje visual y sencillo para hablar en serio de estrategia, sin caer en abstracciones ni perdernos en debates de frameworks. Es la pieza que yo echaba en falta en mi propia caja de herramientas, y precisamente por eso creo que puede cambiar la conversación también en tu organización: porque convierte la agilidad en un verdadero aliado de la dirección.

Con Wardley Mapping, la agilidad deja de ser un conjunto de prácticas y se convierte en la forma de pensar estratégicamente la organización.

LA FOTO: La he creado usando Freepik a partir de esta imagen y su funcionalidad de “Conversar con la IA”. Luego la he manipulado con Pixlr Editor.

Cuando ves una regata desde fuera, puede parecer que gana el barco más ligero o el que lleva las velas más grandes. Pero la diferencia real está en otra parte: en leer el viento y moverse en el momento justo. Anticiparse a la próxima ráfaga es lo que coloca a un equipo en ventaja frente al resto. En la estrategia empresarial ocurre algo parecido: no siempre gana quien tiene más recursos, sino quien entiende mejor su entorno competitivo y sabe moverse antes de que todo cambie.

Si llevamos esta idea al mundo de la agilidad empresarial, vemos que ahí también hemos aprendido, a veces por las malas, a responder rápidamente al cambio. Hacemos retrospectivas, iteramos, adaptamos nuestros equipos, acortamos ciclos de feedback…, pero hay una pregunta que sigue sin tener una buena respuesta: “¿Y si, en lugar de reaccionar, pudiéramos anticipar el cambio?”

Piénsalo. ¿Qué pasaría si tu equipo supiera que esa tecnología que estás adoptando está a punto de ser reemplazada por una plataforma más barata? ¿O si tu empresa pudiera detectar que el verdadero valor no está donde estás invirtiendo, sino en algo que aún no está en tu radar?

Este artículo va justamente sobre cómo anticipar el cambio estratégico usando una herramienta poco conocida pero extremadamente poderosa: los Mapas de Wardley.

El problema: tenemos objetivos, no estrategia

La mayoría de las organizaciones que dicen tener una “estrategia”, en realidad tienen un conjunto de iniciativas. Algunas incluso tienen OKRs. Pero pocas pueden responder con claridad a estas preguntas básicas:

• ¿Conozco realmente el entorno en el que estoy operando (mi mercado y mis competidores)?
• ¿Sé qué está cambiando y por qué?
• ¿Sé dónde debería invertir y dónde dejar de hacerlo?

Responder a estas preguntas requiere lo que en el artículo anterior llamamos consciencia situacional. Y ahí es donde entran los mapas de Wardley. A diferencia de otras representaciones más estáticas, los mapas de Wardley te muestran cómo está cambiando el terreno. Así no sólo ves la foto del presente (el AS-IS), sino la trayectoria de cada componente y el cambio que éste traerá (e.d. un TO-BE bastante más completo de lo que estamos acostumbrados).

Sin esta comprensión, lo que llamamos “estrategia” se convierte en una simple lista de intenciones. Con ella, en cambio, puedes tomar decisiones con intención y fundamento.

Aquí entra en juego el coronel John R. Boyd, piloto de la Fuerza Aérea de EE. UU. que en los años 50 ganó fama como uno de los mejores instructores de combate aéreo. Boyd sabía que, en un duelo en el aire, no siempre ganaba el avión más rápido o mejor armado, sino quien mejor entendía la situación y tomaba decisiones antes que el adversario. De esa experiencia nació el OODA Loop (Observa, Orienta, Decide, Actúa).

El modelo es sencillo:

1. Observa: Recoge información sobre lo que está pasando.
2. Orienta: Interpreta esa información con tu experiencia y objetivos.
3. Decide: Elige qué hacer.
4. Actúa: Ejecuta y vuelve a observar.

En un combate, recorrer este ciclo más rápido que tu oponente significa anticipar sus movimientos y forzarle a reaccionar. En los negocios, esa consciencia situacional te da la imagen nítida de tu escenario competitivo, y un ciclo OODA bien ejecutado te proporciona una valiosa ventaja.

Como ves en la imagen, el bucle OODA es un poco más elaborado. Lo importante, a efectos prácticos, es entender que el salto entre Orientar y Actuar suele darse de forma instintiva mientras no encontramos contradicciones claras con nuestro modelo actual del escenario. Así, en lugar de actuar a partir de los datos, como haríamos en ciclos más reactivos —por ejemplo, el PDCA—, en OODA nos anticipamos y actuamos para estar preparados antes de que el cambio ocurra. No esperamos a que la situación nos empuje a actuar, sino que nos colocamos en la posición más ventajosa para cuando el cambio llegue. Porque ésa es la verdadera ventaja: anticipar qué va a ocurrir y adaptarnos mientras otros todavía están decidiendo qué hacer.

El ciclo de la estrategia según Wardley

Simon Wardley no partió de cero al crear la técnica que lleva su nombre. Observó las lecciones milenarias de “El arte de la guerra” de Sun Tzu, quien p.ej. insistía en conocer el terreno antes de mover un solo soldado. Y las conectó con la lógica del OODA Loop de Boyd que, como hemos visto, prioriza moverse antes que el adversario, no sólo más rápido.

Si conoces a los demás y te conoces a ti mismo, ni en cien batallas correrás peligro;
si no conoces a los demás, pero te conoces a ti mismo, perderás una batalla y ganarás otra;
si no conoces a los demás ni te conoces a ti mismo, correrás peligro en cada batalla.

— Sun Tzu, “El Arte de la Guerra”

Wardley cuenta que, en sus primeros intentos de redactar estrategias, cometía un error común: pasaba del propósito directamente a la lista de acciones. Sin pausa para analizar el panorama, estudiar las fuerzas externas o acordar los principios que darían sentido a cada decisión. Ese hueco, comprendió, era donde se jugaba la ventaja.

De ahí surgió su ciclo de la estrategia: un puente claro entre entender el contexto y mover ficha. Un proceso vivo que arranca con la observación y termina, de nuevo, en la observación, porque el terreno nunca deja de cambiar, y lo que ayer era válido hoy puede estar obsoleto.

Wardley diferencia entre dos niveles de intención:

• El propósito o razón de ser de la organización (lo que en inglés denomina “why of purpose”), que responde a “¿para qué existimos?“. Marca la dirección de la organización y es algo que debería cambiar poco.
• El porqué de nuestros movimientos (o “why of movement”), es el porqué de cada movimiento concreto y depende del contexto actual de la organización. Explica la ventaja que queremos ganar con cada movimiento estratégico, e.d. “¿por qué hacemos este movimiento ahora?”.

Es inevitable encontrarnos con sorpresas al ejecutar cualquier plan. Por eso, al planificar, deberíamos tomar decisiones como cuando cruzamos un río tanteando las piedras: sabemos hacia dónde queremos ir, pero nos adaptamos según las circunstancias, no sólo reaccionando a lo inesperado, sino también anticipándonos y preparándonos para ello. Así, nuestros movimientos no serán improvisados sino deliberados y conscientes de “el porqué” de los mismos.

Como he dicho antes, Wardley se inspira en “El Arte de la Guerra” para desglosar el porqué del movimiento. En la imagen puedes ver cada paso:

• Paisaje: El mapa de todos los componentes y sus interacciones; describe el terreno competitivo y cómo se entrega valor.
• Clima: Las fuerzas externas que influyen en el paisaje y están fuera de nuestro control; aquí se incluyen patrones climáticos (tendencias inevitables, como la comoditización tecnológica) que podemos aprovechar o mitigar.
• Doctrina: Principios universales que funcionan en cualquier entorno y sirven de base para actuar, como “fomentar la comunicación” o “centrarse en las necesidades del usuario”.
• Liderazgo: Tomar decisiones estratégicas alineadas con todo lo anterior, aplicando jugadas competitivas (o “gameplays”). P.ej. “subcontratar un componente” o “invertir en innovación para ganar ventaja”.

Como ves, Wardley Mapping es mucho más que dibujar un mapa: es una técnica de planificación estratégica. Y aun así, como vimos en el artículo anterior, el simple hecho de crear y compartir un mapa ya aporta enorme valor.

Conclusiones

Todo esto nos devuelve a la pregunta con la que empezamos: “¿y si, en lugar de reaccionar, pudiéramos anticipar el cambio?”.

Agile nos enseñó a adaptarnos rápido, pero eso no basta. Las organizaciones verdaderamente ágiles son las que se posicionan antes que las demás, porque entienden el terreno, las fuerzas imperantes y sus propias capacidades.

No puedes predecir el futuro, pero ciertamente puedes anticiparte.

— Simon Wardley

El ciclo de la estrategia de Wardley se integra de forma natural con el bucle OODA: primero observas el terreno y el clima que pueda afectarlo; después orientas tu marco de actuación aplicando la doctrina; a continuación decides cuál será tu movimiento estratégico y actúas; y todo ello bajo un propósito compartido.

Wardley Mapping te permite lograr esa anticipación, pero no como fruto de corazonadas ni de golpes de suerte, sino como el resultado de observar con método, reconocer patrones y actuar con principios claros. El ciclo de la estrategia de Wardley es la disciplina que convierte la adaptación en ventaja.

Si te interesa conocer Wardley Mapping de primera mano de su autor, aquí te dejo esta presentación titulada “Crossing the River by Feeling the Stones” (Cruzando el río tanteando las piedras).

LA FOTO: He escogido esta imagen de una regata porque concentra en una escena la idea central del artículo. En el mar, como en los negocios, no basta con reaccionar cuando sopla el viento: hay que anticipar dónde estará la próxima ráfaga y colocarse allí antes que los demás. Y es que, como hemos visto, ésa es la esencia de la estrategia.

Foto de Wim van ‘t Einde en Unsplash