A veces, incluso tras varios intentos por “ser más ágiles”, las organizaciones siguen sin ver resultados reales: equipos ocupados, muchas “ceremonias”, pero poca mejora en la capacidad de adaptación o en la conexión con la estrategia. En ese punto, hace falta algo más que seguir aplicando recetas. Flight Levels —una propuesta desarrollada por Klaus Leopold— ofrece una forma distinta de observar el trabajo, entender bloqueos estructurales y coordinar acciones más allá de los equipos. Lo descubrí hace años, lo he utilizado en varios contextos, y su último libro (co-escrito con Siegfried Kaltenecker), titulado precisamente “Flight Levels. Leading Organizations With Business Agility” me ha dado pie para compartir algunas claves que te pueden resultar útiles si estás buscando una transformación más efectiva.
Mi interés por Flight Levels comenzó, como tantas otras cosas, con una lectura. En 2018 descubrí el libro “Practical Kanban”, que me ayudó a afianzar conceptos sobre el diseño de sistemas Kanban. Poco después leí “Rethinking Agile” (que puedes encontrar traducido al castellano como “Reconsiderando Agile”), ambos de Klaus Leopold. Fue en ese primer libro donde Leopold introdujo una metáfora que entonces llamó Kanban Flight Levels. Me llamó la atención de inmediato: ofrecía una forma de visualizar el trabajo en diferentes planos organizativos, manteniendo una perspectiva sistémica sin perder de vista lo operativo.
Revisando mis notas de entonces, veo que escribí esto:
Esta metáfora respalda la idea de una organización jerárquica. Entre los aspectos positivos, ayuda a los directivos a verla como una herramienta útil. Entre los negativos, puede dificultar el paso hacia una organización diferente.
No iba yo desencaminado. Con los años, el modelo ha evolucionado, ha dejado de estar ligado exclusivamente a Kanban, ha ganado cuerpo y hoy se presenta como Flight Levels. A mí me gusta especialmente porque es un excelente marco de observación y coordinación sistémica para mejorar la agilidad empresarial. Precisamente porque he descubierto que permite desactivar esa preocupación que yo señalaba en mis notas acerca de que podría convertirse en una herramienta para perpetuar los sistemas en curso en vez de mejorarlos.
Desde mis primeros acercamientos a Flight Levels he aplicado este enfoque en distintos contextos y lo he ido mencionando en varias ocasiones. En 2018 lo cité en mi artículo Las dos caras de la eficiencia, al abordar un reto habitual en muchas organizaciones: cómo medir la eficiencia de flujo cuando se trabaja con iniciativas demasiado grandes para ser abordadas por un único equipo. Más adelante, en 2021, volví a referirme a este enfoque en mi charla titulada Transformar por niveles, donde contaba cómo había aplicado este enfoque en un cliente para mejorar su agilidad empresarial. En aquella ocasión, me centré especialmente en el valor práctico de la metáfora que sustenta el modelo. Incluso en 2023 lo mencioné, aunque de forma más lateral, en el artículo This is not your problem —una especie de texto-ómnibus en el que me temo que la idea quedó algo diluida entre otros muchos conceptos.
A estas alturas, sentía que ya tocaba dedicarle un espacio propio. No sólo por lo que aporta como enfoque práctico, sino porque ofrece una mirada distinta —y necesaria— sobre cómo mejorar la agilidad empresarial
¿Qué son los Flight Levels y por qué importan?
Como ya he mencionado, Flight Levels surge como una metáfora que trata de ayudar a implantar Kanban en grandes organizaciones más allá de equipos individuales: el difícil reto de “escalar” la agilidad. Nos ofrece un modelo mental mediante el cuál vemos una organización a tres diferentes niveles de altitud:
- el nivel 1 (más bajo) se enfoca en los equipos que crean productos y/o servicios,
- el nivel 2 (intermedio) se encarga de la coordinación de las diferentes cadenas de valor,
- y el nivel 3 (más alto) es donde se decide y supervisa la estrategia.
En la imagen, basada en las ilustraciones del libro “Repensando Agile” de Klaus Leopold, vemos que el Nivel de Vuelo 1 (FL1) se dibuja con drones volando a muy baja altitud. En esta metáfora, este nivel de vuelo representa al nivel operacional, donde se crean las funcionalidades, los entregables, las tareas del día a día…
El Nivel de Vuelo 2 (FL2), ilustrado con aviones que vuelan a mayor altitud que los drones y desde los que se puede ver una mayor extensión del territorio, representa a la coordinación del trabajo de principio a fin (end-to-end). Aquí se orquesta cómo fluyen las tareas entre distintos equipos, se priorizan iniciativas compartidas y se resuelven bloqueos que los equipos, por sí solos, no pueden gestionar. Desde este nivel se puede generar trabajo para los equipos (FL1) y/o actuar como puente entre lo operativo y lo estratégico.
Y finalmente, el Nivel de Vuelo 3 (FL3) está dedicado a la estrategia. Empleamos un satélite para indicar que es un nivel altísimo desde el que no podemos ver los detalles, pero sí se pueden ver (y anticipar) dinámicas globales. En este nivel se define en qué quiere enfocarse la organización, qué acciones impulsan ese rumbo y cómo se evaluará el progreso. Es habitual que aquí se trabaje con herramientas como OKRs, aunque el modelo no prescribe ninguna en particular.
Además, en el modelo Flight Levels hay dos conjuntos de actividades: las de diseño del sistema y las del diseño del cambio.
Las actividades de diseño del sistema se deben aplicar en cada nivel y son las siguientes:
- Visualizar la situación
- Crear foco
- Establecer interacciones ágiles
- Medir el progreso
- Operar y mejorar
Estas actividades ayudan a entender y mejorar el sistema actual de trabajo. Son el núcleo técnico del modelo y seguramente te recuerden un poco a las prácticas del método Kanban. Ambas propuestas promueven la visualización del trabajo, la limitación del trabajo en curso, la gestión del flujo y la mejora continua basada en datos. La diferencia clave es que Flight Levels extiende estas prácticas más allá del nivel de equipo, aplicándolas también a la coordinación entre equipos y a la toma de decisiones estratégicas. Así, toma inspiración del pensamiento Kanban, pero lo adapta para abordar la agilidad empresarial desde una perspectiva más amplia y sistémica.
Y las actividades de diseño del cambio, que ayudan a diseñar cómo introducir Flight Levels en una organización, asegurando que el proceso de transformación sea enfocado, participativo y sostenible. Son las siguientes:
- Aclarar desde dónde partes
- Enfocarse en la mejora
- Construir una coalición impulsora del cambio
- Involucrar a las personas
- Aplicar un enfoque ágil
Si te recuerdan a los aceleradores de Kotter, no es casualidad: “Leading Change” aparece entre la bibliografía empleada para escribir el libro.
Con esto deberías tener suficiente para saber si te interesa o no esto de los Flight Levels. Si es así, creo que te merecerá la pena seguir leyendo porque en el resto del artículo trato de explicar qué aporta el libro, aunque desde luego no será un sustituto de su lectura, la cuál abiertamente recomiendo. No sé si la lectura es sustituta de la asistencia a las formaciones porque no he asistido a ninguna de las que ofrecen desde la Flight Levels Academy. Por lo que he visto, una gran parte del libro está basada en la extracción de conocimiento práctico en forma de patrones. Ya sabes: “si te encuentras una situación como ésta y quieres obtener este resultado, a mí me ha funcionado esto”. Así que, como casi siempre, supongo que todo dependerá de cuáles son tus condiciones de partida y la experiencia de quien te imparta la formación.
¿Cómo se estructura el libro?
Capítulos 1 y 2: Introducción a Flight Levels
El libro hace una brevísima introducción a Flight Levels en el primer capítulo pero que, si no lo conoces previamente, creo que no está de más leerla. El capítulo 2 es también interesante porque se centra en los principios que guían el diseño e implementación de sistemas de trabajo con Flight Levels. Es curioso cómo habla mucho de tableros, de flujo de trabajo, etc, pero se ha apartado de Kanban hasta el punto de apenas mencionarlo. Sin embargo, sí abraza conceptos como agilidad o pensamiento sistémico como piezas principales del modelo.
Más o menos ya te he hecho “spoiler” de estos dos primeros capítulos. Aun así, insisto en que si no has leído nunca nada acerca de Flight Levels, merecen ambos la pena.
Capítulo 3: Coordinación en FL2
Luego entra directamente a hablar de cómo diseñar sistemas para FL2 (capítulo 3) de un modo muy práctico. Me parece una buena decisión por lo que los propios autores explican: no tiene sentido volver a explicar lo que ya está bien documentado en muchos otros libros sobre el trabajo en equipos. Lo valioso de Flight Levels está en cómo conectar esos equipos con la coordinación y la estrategia. Para ello introduce el concepto de ruta de vuelo, que describe cómo fluye el trabajo a través de la organización, desde un evento inicial hasta el resultado deseado.
A diferencia de un flujo único, como en muchos tableros Kanban, en FL2 puede haber varias rutas distintas, según el tipo de ítem, su urgencia o su origen. (Sin nombrarlas, se refiere a las clases de servicio de las que hablamos en Kanban). Estas rutas pueden atravesar varios equipos o incluso niveles de vuelo. Definirlas y visualizarlas ayuda a entender cómo fluye realmente el trabajo en la organización y a coordinar mejor la entrega de valor de principio a fin. Para ello, este capítulo nos presenta 14 patrones de tableros de nivel 2 con los que modelar diferentes situaciones. Quizás podrían haber sido menos porque algunos son simplemente variaciones de otros, pero son una manera muy útil de dar respuesta a típicos retos que nos encontramos en “la vida real”, y nos pueden servir de entrenamiento para cuando los árboles no nos dejan ver el bosque.
Voy a poner como ejemplo el patrón número del 4 (“Conectar upstream y downstream”) con esta ilustración adaptada de la original del libro.
Sin un patrón claro, tu tablero Kanban puede parecer sólo un flujo caótico de tareas. Pero al usar la estructura que muestra la imagen —explora, decide, entrega— el tablero empieza a cobrar sentido. Las columnas de la izquierda ayudan a entender el problema y a la derecha se desarrollan y entregan esas soluciones. El punto clave está en la transición: cuando dejas de explorar y te comprometes a construir. Creo que visualizar este cambio lo cambia todo.
De este capítulo me ha gustado especialmente que los autores dedican un apartado específico a cómo abordar los bloqueos, que incluya además un alegato claro contra la práctica de mover tarjetas hacia atrás en el flujo de trabajo. La ilustración de la página 106 (fig. 3-26) lo representa con ironía: un equipo detecta un problema durante la revisión y, en lugar de tratarlo ahí mismo, lo devuelve al inicio del tablero como si reiniciar el proceso resolviera la causa de raíz. El resultado es una mezcla de frustración, confusión y pérdida de contexto. Esta escena resume bien el mensaje central: en lugar de fomentar el devolver trabajo hacia atrás (o backflow) como solución por defecto, deberíamos enfrentar los problemas donde se manifiestan, haciendo del flujo de trabajo un espacio de aprendizaje y mejora continua. Es una idea que también desarrollo en mi presentación Cómo tratar defectos con Kanban, que suelo usar con los equipos con los que trabajo.
También dedica una parte importante de este capítulo a explicar cómo crear foco. Si me permites otro “spoiler”: simplemente explica que en este nivel hay que aplicar Kanban.
En la próxima entrega continuaré con la reseña del libro. Creo que, de momento, para volver al blog no está mal. 🙂
Si me dejas comentarios por LinkedIn, por Bluesky o incluso por la caja de comentarios aquí abajo, podremos continuar la conversación.