Ahora damos un paso adelante con el Observatorio de Scrum Manager: una publicación periódica con formato editorial que amplía y enriquece la forma en que compartimos conocimiento ágil.

Cada edición recoge los mejores análisis, las conversaciones más valiosas y los recursos más prácticos que generan los más de 50.000 profesionales de la comunidad Scrum Manager.

Un formato pensado para que cada número merezca tu tiempo.

The post Nuevo formato para el conocimiento ágil: nace el Observatorio de Scrum Manager appeared first on Blog.

Hace unas semanas hablamos de este tema en Comunidad, y hemos querido ampliarlo.

El atractivo del juego

Cuando Karl Kapp definió la gamificación como «el uso de mecánicas, estéticas y dinámicas basadas en juegos para involucrar a las personas, motivar la acción, promover el aprendizaje y resolver problemas» (Kapp, 2012), probablemente no imaginó que los equipos scrum terminarían convirtiendo sus dailies en partidas de rol.

La promesa es seductora: la gamificación puede aumentar la motivación intrínseca y el compromiso. Y tiene sentido. Los juegos activan nuestros centros de recompensa, generan dopamina y nos mantienen enganchados. ¿Por qué no aplicar estos principios en el mundo agile?

Cuando la gamificación funciona

1. Facilitando el aprendizaje inicial

Los juegos educativos mejoran significativamente la retención del conocimiento y la transferencia de habilidades.

En el contexto ágil, herramientas como el Ball point game o el Marshmallow challenge no son meros entretenimientos. Son laboratorios seguros donde los equipos pueden experimentar con iteraciones, mejora continua y colaboración sin el riesgo de comprometer un sprint real.

2. Rompiendo barreras de comunicación

El Planning poker no es popular por casualidad. Fomenta una participación equitativa y reduce el sesgo de anclaje. El elemento lúdico desarma las jerarquías y permite que las voces más tímidas del equipo se expresen con la misma fuerza que las dominantes.

3. Visualizando el progreso y generando momentum

Los burn down charts gamificados, los avatares que avanzan por un tablero o las barras de progreso tipo videojuego aprovechan lo que se llama «feedback épico». Esta retroalimentación inmediata y visual genera «flow»: ese estado de concentración donde el tiempo parece detenerse.

Cuando solo estamos jugando a ser ágiles

1. La trampa de la motivación extrínseca

La gamificación mal aplicada puede destruir la motivación intrínseca que pretende fomentar. Las recompensas externas pueden socavar la motivación intrínseca, especialmente en tareas creativas.

Cuando convertimos cada tarea en puntos, cada sprint en una competición y cada retrospectiva en un juego, estamos enviando un mensaje peligroso: el trabajo en sí mismo no es lo suficientemente interesante o valioso. Necesita ser «divertido» para que valga la pena.

2. El síndrome del «Agile theater»

Cuando la gamificación se convierte en el foco en lugar del valor entregado al cliente, estamos haciendo teatro, no desarrollo ágil: equipos que dedican más tiempo a actualizar sus avatares en el tablero gamificado que a refinar el backlog; retrospectivas que son pura diversión pero que nunca generan mejoras reales; dailies convertidas en shows donde importa más el formato que la sincronización real del equipo…

3. La infantilización

La gamificación es útil y puede ser efectiva, pero eso no significa que deba aplicarse constantemente y de forma superficial. Corremos el riesgo de enviar un mensaje poco motivador: los adultos profesionales necesitan ser manipulados como niños para hacer su trabajo.

Como toda técnica, es muy importante aplicarla en contextos adecuados y ser conscientes de con quién la aplicamos. Quizás a nuestro desarrollador senior no le aporte nada positivo mover un muñequito por un tablero para visibilizar su progreso. Incluso puede llegar a sentirse infantilizado.

Criterios para una gamificación efectiva

1. Alineación con objetivos reales

La gamificación debería estar perfectamente alineada con los objetivos intrínsecos de la actividad. En scrum, por ejemplo, cualquier elemento gamificado debe contribuir directamente a entregar valor al cliente, no solo a hacer el proceso más «divertido».

2. Voluntariedad y autonomía

La autonomía es fundamental para la motivación. La gamificación impuesta es contraproducente. Los equipos deben elegir si quieren gamificar y cómo hacerlo. Evitamos así efectos como el de la infantilización.

3. Profundidad sobre superficialidad

Lo ideal es buscar una «gamificación significativa»: aquella que conecta con los valores y objetivos personales de los participantes. No se trata de pegar badges y puntos a todo, sino de crear experiencias que resuenen con las motivaciones profundas del equipo.

4. Temporalidad y evolución

La novedad es parte del atractivo de la gamificación, pero también su talón de Aquiles: su efecto puede decaer con el tiempo. La solución no es más gamificación, sino saber cuándo retirarla o evolucionar hacia formas más maduras.

Un marco de decisión pragmático

Gamifica cuando:

• El equipo es nuevo en agilidad y necesita aprender conceptos.
• Hay problemas de comunicación o participación desigual.
• El equipo lo solicita explícitamente y diseña sus propias reglas.
• Es temporal y tiene objetivos de aprendizaje claros.
• Complementa, no reemplaza, las prácticas ágiles fundamentales.

No gamifiques cuando:

• Se percibe como una imposición desde arriba.
• Distrae del objetivo principal de entregar valor.
• Se convierte en el foco en lugar de ser una herramienta.
• Infantiliza o trivializa el trabajo profesional.

Más allá del juego

La gamificación no es inherentemente buena o mala: como cualquier herramienta, su valor depende de cómo, cuándo y por qué la usamos. El peligro no está en usar juegos para facilitar el aprendizaje o mejorar la colaboración. El peligro está en confundir el medio con el fin.

La próxima vez que alguien proponga gamificar, haz preguntas, revisa el contexto y ten en cuenta a tu equipo.

Bibliografía

• Bogost, I. (2011). Gamification is Bullshit. The Atlantic. Disponible en: https://www.theatlantic.com/technology/archive/2011/08/gamification-is-bullshit/243338/
• Csikszentmihalyi, M. (1990). Flow: The Psychology of Optimal Experience. Harper & Row.
• Deci, E. L., Koestner, R., & Ryan, R. M. (1999). «A meta-analytic review of experiments examining the effects of extrinsic rewards on intrinsic motivation.» Psychological Bulletin, 125(6), 627-668.
• Deterding, S., Dixon, D., Khaled, R., & Nacke, L. (2011). «From game design elements to gamefulness: defining gamification». In Proceedings of the 15th International Academic MindTrek Conference, 9-15.
• Hamari, J., Koivisto, J., & Sarsa, H. (2014). «Does gamification work? A literature review of empirical studies on gamification.» In 47th Hawaii International Conference on System Sciences, 3025-3034.
• Kapp, K. M. (2012). The Gamification of Learning and Instruction: Game-based Methods and Strategies for Training and Education. Pfeiffer.
• Koivisto, J., & Hamari, J. (2019). «The rise of motivational information systems: A review of gamification research.» International Journal of Information Management, 45, 191-210.
• Mahnic, V., & Hovelja, T. (2012). «On using planning poker for estimating user stories.» Journal of Systems and Software, 85(9), 2086-2095.
• McGonigal, J. (2011). Reality Is Broken: Why Games Make Us Better and How They Can Change the World. Penguin Press.
• Mora, A., Riera, D., González, C., & Arnedo-Moreno, J. (2017). «Gamification: a systematic review of design frameworks.» Journal of Computing in Higher Education, 29(3), 516-548.
• Nicholson, S. (2015). «A recipe for meaningful gamification.» In Gamification in Education and Business, 1-20. Springer.
• Pink, D. H. (2009). Drive: The Surprising Truth About What Motivates Us. Riverhead Books.
• Ryan, R. M., & Deci, E. L. (2000). «Self-determination theory and the facilitation of intrinsic motivation, social development, and well-being.» American Psychologist, 55(1), 68-78.

The post Gamificación: cuándo funciona y cuándo solo es jugar a Agile appeared first on Blog.

En este artículo queremos presentar los más extendidos. Se trata de una introducción para entender, a grandes rasgos, las diferencias entre ellos, y determinar qué factores pueden ser más importantes al elegir entre uno u otro.

Modelos de escalado ágil: conceptos básicos

Los modelos de escalado ágil son marcos o enfoques que ayudan a las grandes organizaciones a mantener los beneficios de Agile mientras gestionan sistemas y equipos más grandes y complejos. Proporcionan herramientas y prácticas para coordinar y gestionar múltiples equipos ágiles trabajando en el mismo producto o proyecto.

Mientras que las metodologías ágiles como Scrum o Kanban suelen centrarse en la dinámica y la entrega de un solo equipo, el escalado ágil se ocupa de cómo asegurar que múltiples equipos puedan colaborar eficazmente.

La elección de un modelo u otro dependerá del contexto de cada organización; de factores tales como el tamaño y la complejidad del proyecto, el tipo de cultura existente, y la experiencia que ya se tiene en agilidad y con modelos específicos.

Modelos de escalado ágil

Antes de explorar algunos modelos de escalado ágil, es importante entender que estos modelos son muchos y muy diferentes en su enfoque y estrategia. Este post no pretende ser una guía exhaustiva sino una presentación para orientar. El escalado ágil es un tema complejo que requiere investigación, estrategia y, a ser posible, asesoría.

Scaled Agile Framework (SAFe)

Imagina que tienes un gran edificio con muchos pisos. En cada piso, la gente está trabajando en partes diferentes de un proyecto grande. SAFe es como un sistema de ascensores y escaleras que ayuda a todos a coordinar su trabajo y a moverse en la misma dirección.

SAFe es uno de los marcos más populares. Su objetivo es proporcionar una estructura integral que guíe a las organizaciones en la implementación de prácticas Agile en múltiples equipos y niveles.

Características básicas

1. Proporciona una estructura que facilita la coordinación y colaboración a través de toda la organización sin sacrificar los beneficios de la agilidad.
2. Se centra en principios Lean y Agile: pensamiento sistémico, la integración de prácticas de control de calidad durante el desarrollo, la reducción del trabajo en curso y la entrega rápida y frecuente de valor.
3. Es un marco muy estructurado y requiere una inversión significativa de tiempo y recursos para su implementación.
4. Puede adaptarse a las necesidades de cada organización mediante cuatro configuraciones:
   • Essential SAFe: el punto de partida. Incluye el nivel de Equipo y el nivel de Programa, donde varios equipos ágiles se coordinan en un Agile Release Train (ART).
   • Large Solution SAFe: incluye el nivel Large Solution para coordinar múltiples ARTs que trabajan en soluciones grandes y complejas.
   • Portfolio SAFe: incluye el nivel Portfolio, que conecta la ejecución con la estrategia de negocio.
   • Full SAFe: combina todos los niveles anteriores (Team, Program, Large Solution y Portfolio) para organizaciones de gran escala.

Cada configuración tiene su propio sistema de roles, artefactos y procesos.

Large-Scale Scrum (LeSS)

Imagina que tienes varios equipos que juegan un solo juego grande. Todos los jugadores necesitan saber qué está pasando en todo el campo, no sólo en su parte del juego.

LeSS fue desarrollado por Bas Vodde y Craig Larman en el año 2005. Es un marco de trabajo que amplía Scrum para ser usado en equipos de desarrollo más grandes. Extiende los principios de Scrum de un solo equipo a múltiples equipos que trabajan en el mismo producto.

Es una solución más simple y ligera en comparación con otros marcos de escalado. Su enfoque es mantener la agilidad mientras se escala, en lugar de añadir capas adicionales de gestión o burocracia.

Características básicas

1. Se enfoca en mantener la organización lo más plana y flexible posible. Se esfuerza por añadir lo mínimo. Su filosofía es que el escalado no debería complicar innecesariamente las cosas.
2. Hay un único Product Backlog y un único Product Owner para todos los equipos que trabajan en el producto. Esto garantiza una visión y dirección coherente para el producto.
3. Introduce algunos eventos para facilitar la coordinación y la integración entre equipos, como la revisión general (overall sprint review) y la retrospectiva general (overall retrospective).
4. Identifica varias áreas de enfoque, como la coordinación y la integración entre equipos, la arquitectura y el diseño, y la adaptación organizacional.
5. Hay dos variantes:
   • LeSS básico: para hasta 8 equipos de no más de 8 personas cada uno. Todos los equipos trabajan juntos en un único producto.
   • LeSS Huge: para más de 8 equipos. Los equipos se agrupan en «Requirement Areas» («Áreas de Requerimientos»). Cada una de estas áreas funciona como un clúster de LeSS básico, con su propio Product Owner. Sin embargo, todas están orientadas hacia un único producto global con un Product Owner general.
6. Se trata de escalar Scrum y de cambiar la estructura organizacional y reducir las jerarquías, silos y complejidades innecesarias.

Nexus

Tenemos una gran orquesta con varios grupos de músicos. Hay un grupo especial, el equipo de integración Nexus, que actúa como el director de orquesta, asegurándose de que todos los músicos están en sincronía y tocando juntos de manera armoniosa.

Nexus es otro modelo de escalado ágil desarrollado por Scrum.org y co-creado por Ken Schwaber. Su propósito es coordinar los esfuerzos de hasta nueve equipos de Scrum que trabajan en un solo producto, siguiendo los principios de Scrum.

Características básicas

1. Se centra en la integración. Los equipos deben integrar su trabajo regularmente para garantizar que lo que se está produciendo sea un incremento potencialmente entregable al final del sprint.
2. Añade y realiza ajustes a roles, eventos y artefactos presentes en Scrum para abordar las complejidades de múltiples equipos trabajando en un solo producto:
   • Nexus integration team: es un equipo responsable de garantizar que los diferentes equipos trabajen juntos de manera efectiva. Su objetivo es coordinar, entrenar y supervisar las actividades necesarias para garantizar que se entregue un incremento al final del sprint.
   • Además de los eventos de Scrum, se añaden otros como el refinamiento del backlog a nivel de Nexus, daily scrum de Nexus, planificación del sprint a nivel de Nexus y revisión y retrospectiva a nivel de Nexus.
   • Aunque utiliza los mismos artefactos, la naturaleza y el propósito de estos artefactos se expanden para considerar múltiples equipos.

Es importante comprender que, aunque hay similitudes en la nomenclatura de los eventos, roles y artefactos, las responsabilidades y el alcance pueden variar cuando se trata de escalar con Nexus en comparación con Scrum a nivel de equipo.

Elegir el modelo de escalado ágil adecuado

Elegir un modelo de escalado adecuado puede ser una tarea desalentadora, entre otras cosas, porque hay que considerar diversos factores. Por ejemplo:

Tamaño y complejidad de la organización

Los modelos de escalado ágil están diseñados para manejar diferentes tamaños de organizaciones. Por ejemplo, SAFe se adapta a organizaciones de gran tamaño con numerosos equipos de desarrollo; mientras que LeSS puede ser más adecuado para medianas y grandes empresas.

Del mismo modo, la naturaleza y la complejidad de un proyecto pueden influir en la elección del modelo de escalado ágil. Por ejemplo, si un proyecto tiene muchas dependencias y requiere una coordinación intensiva entre múltiples equipos, un modelo más estructurado como SAFe puede ser útil. Pero si el proyecto es menos complejo, LeSS o Nexus quizás sean más adecuados.

Madurez Agile actual

Si nuestros equipos ya están familiarizados con metodologías ágiles, puede ser más fácil adaptarse a un modelo de escalado que se basa en esas metodologías. Por ejemplo, si nuestro equipo ya ha trabajado con Scrum, los modelos de escalado ágil más adecuados podrían ser LeSS o Nexus para que la progresión sea natural.

Por el contrario, si estamos empezando desde cero o queremos incorporar prácticas de Lean y Kanban, SAFe podría ser más apropiado.

Cultura organizacional

El éxito de cualquier modelo de escalado ágil depende de la cultura de una organización. Por ejemplo, modelos como LeSS, que requieren un cambio significativo hacia un enfoque centrado en el equipo, podrían no ser adecuados para organizaciones con una cultura jerárquica fuerte. En este caso, es posible que prefiramos un modelo más estructurado como SAFe.

Flexibilidad

Hay modelos de escalado que ofrecen más flexibilidad y pueden adaptarse a las necesidades únicas de nuestra organización. Por eso es importante estudiarlos todos y saber qué puede aportarnos cada uno y hasta qué punto se podrían adaptar sin que se perdiese la esencia del propio modelo.

Recursos disponibles

La adopción de un modelo de escalado ágil puede requerir una inversión significativa de tiempo y recursos. Por ejemplo, la formación del personal, la contratación de coaches ágiles y posiblemente la reestructuración de equipos. Es esencial tener en cuenta los recursos disponibles al elegir un modelo de escalado ágil.

Metas y resultados esperados

Cada modelo de escalado ágil tiene sus propias fortalezas y debilidades. Por lo tanto, debes considerar qué modelo se alinea mejor con los objetivos específicos de tu empresa. Por ejemplo, si la velocidad de entrega es una prioridad para tu organización, podrías preferir un modelo que se centre en la entrega continua y la eliminación de cuellos de botella, como DevOps.

Recuerda, el mejor modelo de escalado ágil es el que se alinea con las necesidades, la cultura y la madurez Agile de nuestra organización. No se trata de elegir el modelo más popular, sino el que mejor apoyará nuestra transformación Agile.

Diagnosticar antes de elegir

Antes de elegir un modelo, es fundamental entender el punto de partida. Para ello podemos recurrir a herramientas como AgiLevel. Se trata de una guía estratégica de escalado ágil que nos ayuda a analizar el terreno y saber dónde concentrar esfuerzos y recursos.

Características básicas de AgiLevel

1. AgiLevel no es un modelo de escalado ágil, sino una guía estratégica compatible con cualquiera modelo de escalado.
2. Propone un sistema para evaluar el nivel de agilidad de la empresa en base a los principios y valores ágiles.
3. Con este análisis se identifican las áreas más susceptibles al cambio, para guiar la estrategia de escalado de forma que armonice con la realidad de la empresa: en qué punto se encuentra culturalmente, qué tipo de productos o servicios ofrece, qué apoyo directivo hay… entre otros aspectos.

Escalar en agilidad no implica seguir un enfoque único. Los modelos de escalado ágil tienen fortalezas y diseños específicos. La clave para una transformación Agile exitosa radica en entender las necesidades y el contexto únicos de nuestra organización, y elegir el modelo que mejor se alinee con ellos.

Además, independientemente del modelo que se elija, el objetivo final debe ser mantener los valores y principios Agile, fomentando una cultura de colaboración, flexibilidad y aprendizaje continuo.

The post Modelos de escalado ágil y cómo elegir appeared first on Blog.

Este artículo, incluido en el libro The Role of Gamification in Software Development Lifecycle y escrito por Leonardo Enrico Schimmelpfeng y Vania Ribas Ulbricht, crea un modelo LMS recurriendo a la agilidad, la gamificación y al Design Thinking. Es una propuesta que no solo pone a las personas con discapacidad en el centro del proceso de diseño, sino que también gamifica el propio desarrollo del sistema, fomentando la motivación y el compromiso del equipo técnico.

Se combinan tres claves fundamentales:

• Accesibilidad, aplicando las recomendaciones del W3C y las directrices WCAG.
• Gamificación, tanto del producto final como del proceso de desarrollo.
• Design Thinking, como marco estructurador del proyecto y herramienta para empatizar con los usuarios reales.

Estos apuntes son especialmente valiosos para profesionales del ámbito educativo y del desarrollo de software que quieran aplicar principios de diseño inclusivo desde el inicio.

Podéis encontrar estos y otros apuntes sobre Design Thinking en scrummanager.com y otros muchos recursos en el Club Agile.

The post Apuntes LMS accesible para personas con discapacidad appeared first on Blog.

Aunque no es un marco de trabajo ágil formalizado, contiene prácticas que la empresa Spotify encontró útiles en su contexto organizativo y que han inspirado a muchas otras organizaciones.

¿Conocéis este modelo? ¿Lo habéis aplicado en vuestra organización? ¡Contádnos vuestras experiencias!

Modelo Spotify: características y elementos

En 2010 la empresa Spotify alcanzó gran popularidad y creció con rapidez. Para mantener su agilidad y velocidad de innovación, decidieron crear su propio enfoque ágil, adaptándolo a su cultura y necesidades únicas. El resultado fue el modelo Spotify.

En 2014 la empresa compartió por primera vez su modelo con el público en dos videos muy conocidos: «Spotify Engineering Culture part 1» y «Spotify Engineering Culture part 2»; aunque desde entonces la empresa ha ido evolucionado y cambiado su enfoque en función de sus necesidades.

Características

El modelo de Spotify continúa evolucionando y sus elementos pueden haberse modificado según las necesidades de la empresa, pero podemos deducir cuatro pilares básicos sobre los que se sustenta:

• Autonomía y confianza: los equipos deben tener autonomía para tomar sus propias decisiones. Tienen la libertad de decidir qué métodos de trabajo usan, cómo organizan su tiempo y cómo resuelven problemas. Esta autonomía se equilibra con la alineación: los equipos deben estar alineados con los objetivos y la misión de la empresa.
• Experimentación y aprendizaje continuo: se anima a los equipos a probar nuevas ideas y aprender de sus éxitos y fracasos. También promueve la idea de «fallar rápido»: si una idea no funciona, es mejor descubrirlo rápidamente y aprender de la experiencia.
• Colaboración y comunicación: todos los elementos que veremos a continuación están diseñados para fomentar la colaboración y para compartir conocimientos.
• Enfoque en el usuario: Spotify pone un fuerte énfasis en la creación de una gran experiencia para el usuario. Por eso, para asegurarse de que el producto final sea atractivo y útil para los usuarios, los equipos son multidisciplinarios.

Elementos

Squad (Escuadrón)

Está formado por un pequeño grupo de personas (entre 6 y 12) que trabajan juntas. Cada escuadrón tiene una misión a largo plazo y un Product Owner.

Es un grupo multidisciplinario que tiene autonomía para decidir qué trabajar y cómo hacerlo, pero debe mantener la coherencia con los objetivos de la empresa. Es decir, un squad puede trabajar siguiendo el marco scrum y otro squad puede trabajar siguiendo lean, siempre y cuando se trabaje bajo un objetivo común.

Tribe (Tribu)

Es un conjunto de squads que trabajan en áreas relacionadas o tienen objetivos comunes. Una tribu normalmente está liderada por un Tribe Leader y está diseñada para facilitar la comunicación y la colaboración entre los squads.

Es importante entender que la tribu no es un «super-escuadrón» con su propio método de trabajo. Más bien, es una estructura organizativa que proporciona apoyo y coordinación a los escuadrones individuales.

Y esto se logra de varias maneras. Por ejemplo:

• Líder de tribu: cada tribu tiene un líder que proporciona apoyo y orientación a los escuadrones. El líder de la tribu no está allí para decir a los escuadrones cómo deben trabajar, es un facilitador que ayuda a eliminar obstáculos y a asegurar que los escuadrones tienen los recursos necesarios. Idealmente, debería tener un buen entendimiento de los diferentes métodos de trabajo que utilizan sus escuadrones. Sin embargo, es más importante que tengan habilidades de liderazgo y comunicación efectivas.
• Demostraciones y reuniones de coordinación: los escuadrones dentro de una tribu pueden tener demostraciones regulares para mostrar su trabajo a otros escuadrones. Esto permite que todos en la tribu se mantengan al tanto de lo que están haciendo los demás y facilita el intercambio de ideas.

Chapter (Capítulo)

Es un grupo de personas con roles similares (por ejemplo, desarrolladores front-end), que trabajan en el mismo squad o en diferentes squads dentro de la misma tribu. Es decir, son transversales a una tribu.

Cada capítulo tiene un líder (Chapter Lead), que suele ser miembro de un escuadrón, por lo que tiene una visión directa de los desafíos que enfrentan los miembros del capítulo. Es responsable del crecimiento personal y profesional de los miembros del capítulo.

Los miembros de un capítulo normalmente se reúnen para compartir conocimientos y mejores prácticas relacionadas con su área de especialización. Por ejemplo, un capítulo de desarrolladores de back-end puede reunirse para discutir nuevas tecnologías y trabajar en la mejora de las habilidades de desarrollo de back-end en toda la tribu.

En definitiva, los capítulos ayudan a organizar y apoyar a las personas que tienen el mismo tipo de rol, para que puedan aprender y crecer juntas profesionalmente.

Guild (Gremio)

Es una estructura organizativa más informal y más amplia que un capítulo. Cualquier persona, sea cual sea su rol, tribu o escuadrón, puede unirse a cualquier gremio o incluso iniciar uno nuevo. Lo que une al grupo es un interés común (una tecnología específica, una práctica de ingeniería, un conjunto de habilidades, etc.).

El objetivo de un gremio es proporcionar un espacio para compartir conocimientos, resolver problemas y aprender en torno a ese interés común. Es decir, es transversal a toda la organización. Fomentan el aprendizaje y la colaboración más allá de los límites de los escuadrones y las tribus.

Pueden tomar muchas formas diferentes dependiendo de las necesidades y la cultura de la organización: pueden ser muy formales, con reuniones regulares y una estructura clara; o más informales y centrados en sesiones de brainstorming.

Tanto los capítulos como los gremios son formas de facilitar la colaboración y el aprendizaje más allá de los límites de los escuadrones individuales, pero se organizan de manera diferente y tienen diferentes ámbitos de aplicación.

Un ejemplo del Modelo Spotify

Supongamos que tenemos una gran empresa de software llamada «TechCorp» que ha adoptado el modelo de Spotify. TechCorp tiene una serie de productos diferentes, por lo que ha organizado su trabajo en varias tribus.

• Tribus: tenemos una tribu de E-commerce, una de Aplicaciones Móviles y una de Data Science.
• Escuadrones: dentro de la Tribu de E-commerce, hay varios escuadrones. Un escuadrón trabaja en el sistema de carrito de compras utilizando Kanban y otro en la interfaz de usuario del sitio web utilizando prácticas de Scrum. Cada escuadrón tiene su propio backlog de trabajo y su propio Product Owner.
• Capítulos: dentro de la tribu de E-commerce, hay varios capítulos. Por ejemplo, todos los desarrolladores front-end de todos los escuadrones forman un capítulo, y todos los diseñadores de UX forman otro.
• Gremios: hay gremios que se extienden por toda la organización. Por ejemplo, hay un gremio de DevOps que incluye a personas de todas las tribus que están interesadas en las prácticas de DevOps.

Desafíos del Modelo Spotify

A pesar de su popularidad y sus fortalezas, el modelo de Spotify tiene sus desafíos. Por ejemplo, puede ser difícil de implementar en empresas con culturas muy diferentes. La autonomía de los equipos requiere confianza y responsabilidad, que puede ser difícil de lograr en organizaciones más tradicionales o jerárquicas.

Además, aunque la autonomía de los equipos puede llevar a la innovación y la adaptabilidad, también puede resultar en inconsistencia y duplicación de esfuerzos. Por ejemplo, dos equipos pueden terminar resolviendo el mismo problema de dos maneras diferentes, lo que resulta en una falta de coherencia para los usuarios finales.

Es importante tener en cuenta que este no es un modelo en sí mismo, sino un conjunto de prácticas ágiles y una forma de organizar equipos. Y, desde luego, no es necesariamente la mejor o única manera de escalar en agilidad.

Necesitaremos investigar para entender los diferentes modelos de escalado ágil y así poder elegir el que mejor se adapte a nuestro contexto organizacional.

The post Modelo Spotify: una forma diferente de escalar en agilidad appeared first on Blog.

La agilidad va más allá de prácticas, tableros o reuniones diarias. Es una mentalidad y tiene que ver con cómo piensa, decide y se relaciona una organización. En Scrum Manager proponemos una mirada más amplia para responder a la gran pregunta: ¿Cómo de ágil es tu empresa realmente?

El riesgo de la agilidad superficial

Imaginemos una organización cuyos equipos «hacen Scrum»: tienen reuniones diarias, realizan retrospectivas, estiman y priorizan; pero su forma de trabajar, tomar decisiones y relacionarse no ha cambiado en absoluto.

En este contexto empieza a haber fricciones culturales: los mandos intermedios microgestionan para que “se haga buen Scrum”, los equipos se sienten presionados a entregar más rápido sin poder influir en el qué ni el cómo, y hay una sensación general de estar aplicando procesos que no aportan el valor prometido. El resultado es una «agilidad de escaparate» que genera mucha frustración y desconfianza.

Y empiezan las preguntas: ¿por qué ocurre esto? Es probable que uno de los factores principales sea la falta de alineación entre tres elementos clave: la estructura organizativa, la cultura empresarial y la forma de trabajar. Da igual que se sigan determinadas prácticas. Cuando la agilidad se convierte en un envoltorio bonito, no hay transformación real y tampoco verdadera agilidad.

AgiLevel: una herramienta para el diagnóstico y la evolución

Para ayudar a las organizaciones a no quedarse en la superficie, en Scrum Manager hemos creado AgiLevel: un modelo de diagnóstico y evolución ágil que se adapta al contexto real de cada empresa.

AgiLevel ofrece una fotografía realista del nivel de agilidad en dos dimensiones complementarias y en el soporte:

• Dimensión operativa: se analizan las prácticas, herramientas, flujos de trabajo, roles, mecánicas operativas… En definitiva, el modo de trabajar en una empresa.
• Dimensión organizativa: se analizan las estructuras, cultura, liderazgo, toma de decisiones. Es decir, cómo es una empresa.
• Soporte: se analiza el grado de apoyo que se tiene en la empresa por parte de directivos.

Ambas dimensiones se cruzan en la práctica. No basta con hacer bien los sprints, si el entorno no acompaña. Por eso, AgiLevel invita a reflexionar sobre cómo trabajamos y cómo somos.

Es un modelo de diagnóstico y mejora continua que reconoce la complejidad de las organizaciones reales y no prescribe un camino único hacia la agilidad. Se basa en principios que pueden adaptarse a cada contexto, permitiendo a las organizaciones evolucionar desde su punto de partida real, no desde un ideal teórico.

El libro de Scrum Master y AgiLevel

AgiLevel cuenta con una guía, y puede verse complementado por nuestro libro de Scrum Master. En él proponemos una visión de Scrum que va más allá de facilitar eventos o eliminar impedimentos.

Ambos libros se actualizan con el conocimiento de la comunidad. El libro de Scrum Master puede servir de apoyo para equipos juniors. Pero es también una propuesta flexible que anima a adaptar según el contexto y a evolucionar desde un punto de partida real.

¿Cómo empezar a usar AgiLevel?

AgiLevel puede aplicarse de forma flexible, según el punto de partida y los recursos disponibles:

Opción 1: explora AgiLevel Canvas

Como primer paso puede ser útil usar la herramienta de AgiLevel Canvas creada por Nicolás Escobar. Es una herramienta visual y sencilla para reflexionar individual o colectivamente sobre la situación actual. 

Ideal para usar en equipos o formaciones.

Opción 2: usar la plataforma EVAL

EVAL permite recoger datos y percepciones desde distintos perfiles y áreas. Puede ser más completa y ofrecer una visión más transversal que la herramienta de AgiLevel Canvas.

Opción 3: acompañamiento externo

Hay profesionales certificados que pueden aplicar el modelo como parte de sus servicios de diagnóstico y transformación, con más profundidad y seguimiento.

Sea cual sea la opción que elijamos, es importante tener en mente que el objetivo no es obtener una nota, sino abrir conversaciones significativas y priorizar acciones de mejora basadas en la realidad.

En resumen…

Si quieres comenzar a aplicar este enfoque, te recomendamos:

1. Descargar el libro de AgiLevel para familiarizarte con el concepto. En caso de conocerlo, puedes usar la herramienta de AgiLevel Canvas.
2. Organizar una sesión de reflexión con tu equipo o cliente utilizando el canvas como guía.
3. Utilizar EVAL para recoger datos. 
4. En caso de necesitarlo, busca un profesional certificado que pueda ofrecerte acompañamiento durante este diagnóstico. 

Si necesitas más recursos u opiniones, únete al Club Agile y comparte tu experiencia con otros profesionales.

¿Qué esperar del proceso?

Al aplicar AgiLevel, se busca obtener:

• Una fotografía clara del nivel de agilidad real, sin autoengaños ni simplificaciones.
• Identificación precisa de frenos y oportunidades de mejora en ambas dimensiones.
• Acciones de mejora concretas adaptadas al contexto específico de la organización.

El valor principal reside en la claridad y la honestidad que aporta el proceso. Muchas organizaciones descubren que lo que creían era un problema técnico es en realidad un desafío cultural más profundo.

Recursos gratuitos para comenzar

En Scrum Manager creemos que la mejora continua empieza con conocimiento compartido. Por eso, todos estos recursos están disponibles de forma gratuita:

• agilevel.com
• AgiLevel Canvas.
• Acceso a EVAL para evaluación personalizada.
• Libro de Scrum Master de Scrum Manager.
• Libro de AgiLevel de Scrum Manager.
• Talleres y foro de comunidad en el Club Agile.

La agilidad no se impone ni se copia. Se construye desde dentro, con reflexión y pequeños pasos. No es una lista que completar ni un estado final que alcanzar. Representa un camino de mejora continua que tiene en cuenta el contexto particular de cada organización.

Para saber cómo de ágil es nuestra empresa podemos usar AgiLevel, que identificará dónde estamos y hacia dónde podemos ir; y una vez claros los objetivos, podemos utilizar los principios y valores de Scrum Master para continuar con el cambio. 

The post ¿Cómo de ágil es tu empresa realmente? appeared first on Blog.

Y lo más importante, ¿puede la perspectiva su origen influir directamente en cómo se implementa? ¡Cuéntanos tu opinión en los comentarios!

Un breve recorrido por el origen de scrum

Scrum como conocimiento emergente (1980)

Scrum no surgió como un diseño teórico impuesto. Sus principios fundamentales comenzaron a manifestarse de forma orgánica en los años 80: ingenieros de empresas como 3M, Fuji, Honda y HP, insatisfechos con los modelos de producción en cascada, comenzaron a desarrollar patrones iterativos con solapamiento de fases.

En 1986 Hirotaka Takeuchi e Ikujiro Nonaka identificaron estos patrones emergentes en su artículo «The New New Product Development Game». Fueron ellos quienes bautizaron este enfoque como «scrum», utilizando la analogía de la formación de rugby. Es decir, identificaron, nombraron y dieron visibilidad a prácticas que ya estaban ocurriendo de forma espontánea.

La primera formalización (1990-1995)

En 1990 Peter DeGrace y Leslie Hulet Stahl publicaron Wicked Problems, Righteous Solutions. En él presentaron una propuesta de desarrollo iterativo basada en los principios identificados por Nonaka y Takeuchi, a la que también llamaron «scrum».

Sin embargo, esta propuesta no sería la más conocida: quienes dieron mayor difusión al término “scrum” fueron Jeff Sutherland y Ken Schwaber durante el congreso OOPSLA (Object-Oriented Programming, Systems, Languages & Applications).

Evolución colaborativa (1995-presente)

En 2001 Sutherland y Schwaber participaron en la creación del Manifiesto Ágil, que ayudó a consolidar muchos de los principios de Scrum dentro de un movimiento más amplio.

Y en 2010 Schwaber y Jeff Sutherland publicaron la primera versión oficial de la Guía Scrum, un documento que ha sido actualizado periódicamente y que representa la visión «oficial» del marco.

Sin embargo, Scrum ha evolucionado de forma continua también gracias a las ideas y prácticas aportadas por la comunidad ágil global. Por ejemplo:

• Al principio las iteraciones (sprints) podían durar desde 1-2 meses; a día de hoy suelen durar desde 1-2 semanas (adaptándose al contexto del equipo y la organización).
• Se incorporaron las reuniones retrospectivas para fomentar la mejora continua.
• Se añadió el refinamiento de la pila de producto (product backlog) como práctica recomendada.
• Se desarrollaron diversas técnicas para estimar (o no estimar) tareas e historias de usuario.
• Se integraron conceptos de tableros kanban para la gestión visual del trabajo, dando origen a prácticas híbridas.
• Se refinó el rol del Product Owner y su relación con los stakeholders.

Perspectivas sobre la propiedad de Scrum

Scrum como conocimiento propietario

Hay quien promueve una visión de Scrum como un marco definido con una guía oficial actualizada periódicamente por sus creadores. Esta perspectiva ofrece:

• Una definición acotada y estandarizada del marco, con roles, eventos y artefactos claramente definidos.
• Un punto de partida estructurado y común que busca mantener la integridad del marco.
• Actualizaciones controladas a través de revisiones periódicas de la Guía Scrum.

Scrum como conocimiento abierto

Otras organizaciones promueven una visión de Scrum como conocimiento común emergente, evolutivo y de dominio público. Esta perspectiva considera que:

• Scrum es un punto de partida, no un destino final o un conjunto rígido de reglas.
• La verdadera potencia de Scrum se desarrolla cuando los equipos aprenden a adaptar el marco técnico estándar a sus necesidades específicas.
• La rigidez conceptual podría limitar la innovación y adaptación necesarias en entornos complejos y cambiantes.
• El conocimiento sobre mejores prácticas pertenece a la comunidad, no a organizaciones específicas.

Impacto en la aplicación práctica

¿Puede el origen de scrum influir en cómo se implementa en una organización? Una empresa que considere Scrum como un modelo propietario probablemente tenga algunas de las siguientes limitaciones:

1. Rigidez operativa. Ceñirse estrictamente a la guía oficial puede generar miedo a “romper” Scrum y, por tanto, miedo a realizar cualquier cambio aunque el contexto lo pida. 
2. Parálisis de innovación. Se espera que todas las mejoras vengan de las actualizaciones oficiales de la guía. Por tanto, no se experimenta con adaptaciones para resolver problemas específicos.
3. Implementación superficial. La obsesión por seguir a rajatabla la guías oficial puede fomentar que se adopten solamente los elementos visibles (ceremonias, roles), pero no los principios subyacentes. Se le da más prioridad a “hacer scrum” que a “ser ágil”.

Quizás lo más adecuado sea buscar el equilibrio: usar la guía oficial como un marco de referencia valioso para comenzar, pero no cerrarse la posibilidad a adaptaciones o cambios dados por el contexto y las necesidades del entorno particular.

A diferencia de otros marcos y metodologías con autoría clara, Scrum emergió de forma colaborativa desde la base profesional, fue identificado y formalizado por profesionales y ha continuado evolucionando gracias a las aportaciones de una comunidad global.

Independientemente de la perspectiva adoptada, es importante mantener el espíritu de mejora continua y adaptación que constituye la esencia de Scrum. Después de todo, la agilidad que Scrum promueve debería aplicarse también a la forma en que entendemos y utilizamos el propio marco.

Referencias

1. DeGrace, P., & Stahl, L. H. (1990). Wicked Problems, Righteous Solutions: A Catalogue of Modern Software Engineering Paradigms. Prentice Hall.
2. Manifesto for Agile Software Development (2001). http://agilemanifesto.org/
3. Palacio Bañares, Juan (2023). «Origen de scrum más allá de los mitos», Navegapolis.
4. Schwaber, K. (1995). «SCRUM Development Process». OOPSLA’95 Workshop on Business Object Design and Implementation.
5. Schwaber, K., & Sutherland, J. (2020). The Scrum Guide: The Definitive Guide to Scrum.
6. Sutherland, J. (2014). Scrum: The Art of Doing Twice the Work in Half the Time.
7. Takeuchi, H., & Nonaka, I. (1986). «The New New Product Development Game». Harvard Business Review, 64 (1), 137-146.

The post El origen de scrum: entre el conocimiento abierto y los modelos propietarios appeared first on Blog.

¿Qué hace realmente un agile coach? ¿Es solo alguien que enseña prácticas ágiles a los equipos? ¿O su impacto va mucho más allá? Ser agile coach no se reduce a transmitir conocimientos sobre agilidad; implica ayudar a los equipos a desarrollar una mentalidad ágil, superar barreras organizacionales y garantizar que los cambios sean sostenibles a largo plazo.

Un agile coach no impone soluciones, sino que guía a los equipos en su evolución según su nivel de madurez. Tiene claro que los cambios serán algo más que aplicar algunas técnicas: puede haber cambios culturales profundos dentro de la organización. Pero para ello necesita empoderar y hacer que los equipos sean autónomos y se autogestionen. No bastará con introducir cambios, deberá asegurarse de que estos se adopten y se mantengan en el tiempo: reforzando regularmente los valores ágiles, realizando retrospectivas y fomentando la mejora continua.

¿Cómo se debe empezar con el agile coaching? Lo primero es desarrollar habilidades clave, tales como la escucha activa, la resolución de conflictos, el liderazgo… Además, debe saber gestionar resistencias al cambio y adaptarse a las particularidades de cada equipo.

Si quieres saber qué implica el agile coaching y qué se necesita para desempeñar este rol de forma efectiva, descarga nuestros apuntes del libro Agile Coaching de Rachel Davies y Liz Sedley.

Puedes descargar apuntes similares en Open Knowledge.

¡Cuéntanos sobre tus experiencias como agile coach o con coaches ágiles en los comentarios!

The post Apuntes Agile Coaching appeared first on Blog.

Exploramos qué son los mapas de empatía y cómo pueden ayudarnos a identificar por qué existe resistencia al cambio en nuestra organización. ¿Los habéis usado alguna vez? ¡Contádnoslo en los comentarios!

¿Qué es un mapa de empatía?

Es una herramienta visual que permite conocer a los usuarios: qué piensan, cómo se sienten, qué experimentan… En Design Thinking se divide en seis cuadrantes, que reflejan diferentes aspectos de la experiencia del usuario:

1. ¿Qué piensa y siente?
   • ¿Cuáles son sus preocupaciones, miedos o deseos?
   • ¿Qué lo motiva o lo frustra?
   • ¿Qué le genera satisfacción o incomodidad?
2. ¿Qué ve?
   • ¿Qué observa en su entorno inmediato?
   • ¿Qué influencias externas afectan su percepción?
   • ¿Qué productos, tendencias o tecnologías lo rodean?
3. ¿Qué dice y hace?
   • ¿Cómo se expresa sobre su problema o necesidad?
   • ¿Qué comportamientos muestra ante otros?
   • ¿Qué actitudes toma en público y en privado?
4. ¿Qué escucha?
   • ¿Qué le dicen amigos, familiares o compañeros?
   • ¿Qué medios de comunicación o redes sociales influyen en su pensamiento?
   • ¿Qué mensajes refuerzan o debilitan su postura?
5. Esfuerzos y frustraciones
   • ¿Qué desafíos enfrenta en su día a día?
   • ¿Qué problemas no ha podido solucionar?
   • ¿Qué situaciones le generan estrés o dificultad?
6. Necesidades y oportunidades
   • ¿Qué necesita realmente para mejorar su situación?
   • ¿Cómo podríamos ayudarle con un producto o servicio?
   • ¿Qué soluciones podrían hacer su vida más fácil?

Pasos para usar el mapa de empatía en la gestión del cambio

En un contexto de gestión del cambio, nuestro mapa de empatía va a tener los siguientes cuadrantes:

• Qué piensa y siente: cuáles son las preocupaciones, miedos y deseos internos.
• Qué ve: qué factores del entorno refuerzan o desafían su punto de vista.
• Qué dice y hace: cómo es su comportamiento y discurso en relación con el cambio.
• Qué escucha: qué influencias externas que afectan su percepción.
• Esfuerzos y frustraciones: qué obstáculos y puntos de dolor encuentra en el proceso de cambio.
• Necesidades y oportunidades: qué recursos, apoyo o ajustes pueden facilitar la transición.

Paso 1: definir el perfil de las personas afectadas

Antes de completar el mapa es fundamental definir a qué grupo de empleados o stakeholders nos dirigimos. ¿Son equipos técnicos, mandos intermedios, directivos? Cada grupo puede tener diferentes preocupaciones y percepciones.

Para ello podemos usar técnicas y herramientas como, por ejemplo:

• Mapas de actores: es una herramienta utilizada habitualmente en Design Thinking para conocer a los usuarios. Puede ayudarnos a identificar y categorizar a las personas involucradas según su nivel de impacto e influencia en el proceso de cambio.
• User persona: es una representación ficticia de un usuario ideal o típico. Para elaborarlos es necesario investigar y analizar datos. Puede sernos útil para crear arquetipos basados en características comunes, motivaciones, temores y barreras ante el cambio.
• Cuestionarios y encuestas: las preguntas pueden ayudarnos a recopilar percepciones generales sobre el cambio y detectar patrones o tendencias en la organización.
• Observación directa: evaluar comportamientos y dinámicas dentro de los equipos puede ser útil, especialmente si lo combinamos con alguna de las herramientas anteriores.
• Análisis de redes organizacionales: conocer a los líderes y puntos clave de comunicación dentro de la empresa nos dará una base sólida desde la que empezar a investigar.

Paso 2: recopilar información

Para poder elaborar el mapa de empatía necesitamos información. La mejor forma de conseguirla es a través de entrevistas, encuestas o sesiones de observación con los empleados afectados por el cambio. Por ejemplo:

• Entrevistas individuales: permiten obtener información detallada sobre percepciones y emociones.
• Focus groups: son discusiones guiadas en grupos de entre 5 y 10 personas, moderadas por un facilitador. Pueden servirnos para identificar patrones comunes dentro de estos grupos y para explorar opiniones, percepciones y actitudes respecto al cambio.
• Encuestas anónimas: son útiles para captar percepciones generales y detectar posibles resistencias.
• Observación en el entorno de trabajo: ayuda a identificar comportamientos que no siempre se expresan verbalmente.

Paso 3: rellenar los cuadrantes del mapa de empatía

Antes de rellenar cada cuadrante con la información recopilada, podemos incluir preguntas clave que puedan ayudarnos a hacer una criba de la información obtenida. Incluso podemos usar estas preguntas para prepararnos para las entrevistas, encuestas o cualquier otra técnica que hayamos decidido usar para recopilar información.

Paso 4: analizar los patrones y extraer conclusiones

Una vez hecho el mapa y una vez completado, es el momento de identificar temas recurrentes que revelen las causas principales de la resistencia. De esta forma, podremos buscar formas de abordar esas preocupaciones: ya sea a través de comunicación, formación o ajustes en la implementación del cambio.

El mapa de empatía es una herramienta visual que puede ayudarnos a gestionar el cambio: nos permite conocer y comprender las verdaderas preocupaciones de los empleados y adaptar estrategias en consecuencia.

¡Ahora es tu turno! Prueba a utilizar el mapa de empatía para identificar resistencias en la gestión del cambio. En el Club Agile hay disponible una plantilla. Entra y descárgala:

The post ¿Un mapa de empatía puede ayudar a identificar resistencias al cambio? appeared first on Blog.

En este artículo hablamos de cada uno de sus niveles, sus propósitos, herramientas y retos comunes.

¿Qué son los Flight Levels?

Flight Levels es un framework ágil desarrollado por Klaus Leopold quien quiso mostrar cómo se puede gestionar el trabajo organizacional desde diferentes niveles:

• Flight Level 3: Estrategia. Define el «qué» de la organización. Define la dirección y las prioridades a medio y largo plazo de la empresa.
• Flight Level 2: Coordinación. Alinea el «cómo» entre equipos. Actúa como puente entre la estrategia y las operaciones, asegurando que los equipos trabajen de manera sincronizada hacia objetivos comunes.
• Flight Level 1: Operaciones. Es el cómo. Aquí es donde los equipos e individuos ejecutan las tareas diarias, producen productos y brindan servicios a los clientes.

Este no es un marco de trabajo rígido. Sirve para identificar dónde es necesario intervenir para lograr mejoras significativas con cambios mínimos en la estructura.

Flight Level 3: Estrategia («qué»)

En este nivel se definen los objetivos estratégicos de la organización. Su propósito es responder preguntas como:

• ¿Qué queremos lograr como empresa?
• ¿Cómo alineamos nuestras prioridades con nuestras capacidades actuales?

Herramientas

Podemos utilizar mapas de estrategia para priorizar esfuerzos y comunicar la visión de la organización de manera clara y comprensible para todos los niveles. 

También podemos recurrir a los OKRs (Objectives and Key Results) para establecer un enfoque y medir el progreso hacia metas específicas.

O podemos usar Hoshin Kanri: un enfoque Lean usado para implementar mejoras estratégicas que abarquen todas las áreas de la empresa.

Retos comunes

El mayor reto es probablemente superar la falta de claridad y comunicación: si los objetivos son ambiguos o demasiado genéricos, no ofrecen una dirección clara y pueden no ser comprendidos por todos los niveles de la organización. Esto genera desconexión entre estrategia y ejecución. Una posible solución podrían ser los workshops para identificar objetivos clave y utilizar herramientas como mapas de estrategia.

Como consecuencia de esta falta de comunicación y claridad puede suceder que las decisiones estratégicas no reflejen las capacidades reales de los equipos. Por ejemplo, cuando se decide duplicar la producción sin considerar limitaciones de personal. Esto genera expectativas irreales o prioridades mal definidas.

Antes de definir los objetivos podría ser aconsejable realizar una evaluación de las capacidades operativas y consultar a los equipos involucrados en su ejecución.

Además, los esfuerzos pueden dispersarse y podemos llegar a perder el foco, si se hacen ajustes constantes. En estos casos lo ideal sería establecer ciclos regulares de revisión estratégica (por ejemplo, trimestrales) para evaluar la relevancia de los objetivos y ajustar solo cuando sea absolutamente necesario.

Flight Level 2: Coordinación («cómo»)

Asegura que los equipos trabajan juntos hacia los objetivos estratégicos. Aquí se identifican dependencias y se resuelven cuellos de botella que impiden el flujo de trabajo.

Herramientas

Podemos usar tableros o mapas para visualizar las dependencias entre equipos y su estado. De esta forma será más sencillo identificar cuellos de botella y permitirá una mejor gestión del trabajo interdepartamental. Por ejemplo, podemos hacer un tablero donde incluyamos las tareas de cada equipo y cómo estas contribuyen a un proyecto común. O podemos elaborar un mapa que conecte los esfuerzos del equipo de diseño con las entregas del equipo de producción.

Otra opción son las reuniones de sincronización: sesiones regulares para alinear prioridades y resolver conflictos. Por ejemplo, marketing y desarrollo pueden reunirse cada 15 días para coordinar lanzamientos de productos.

Retos comunes

Puede suceder que haya una descoordinación entre áreas: los equipos trabajan de manera aislada, lo que genera malentendidos y duplica esfuerzos. A veces esta descoordinación no se aborda hasta que se vuelve una situación crítica. Esta falta de comunicación se puede solventar creando un sistema de alertas tempranas para identificar y abordar posibles bloqueos antes de que afecten al flujo.

Como consecuencia de esta descoordinación y falta de comunicación, se pueden generar cuellos de botella en procesos compartidos. Una posible solución es usar tableros Kanban compartidos que permitan visualizar el flujo de trabajo completo. Estos también ayudarían a visibilizar cómo los equipos están contribuyendo a los objetivos globales. 

Por último, es posible que nos encontremos con cierta competitividad entre equipos: los equipos priorizan sus propios objetivos sobre los de la organización. Esto puede generar muchos conflictos entre departamentos y, como consecuencia, retrasos en las entregas. Por ejemplo, el equipo de ventas promete entregas rápidas sin consultar con el equipo de producción sobre su capacidad.

Flight Level 1: Operaciones («hacer»)

En este nivel los equipos trabajan directamente en las tareas diarias necesarias para entregar valor a los clientes. Su enfoque está en la ejecución eficiente y la mejora continua.

Herramientas

Son fundamentales las herramientas que permitan visualizar el flujo de trabajo. Por ejemplo, los tableros Kanban o Scrum boards.

• Tableros Kanban: permiten gestionar tareas de manera visual, limitar el trabajo en progreso y optimizar el flujo de trabajo.
• Scrum Boards: facilitan la planificación de sprints y el seguimiento del progreso.

Retos comunes

Uno de los mayores retos puede ser la resistencia al cambio. Los equipos prefieren mantener sus prácticas habituales en lugar de adoptar mejoras. No buscan formas de optimizar su rendimiento, ni quieren hacerlo. En estos casos puede ser útil introducir cambios graduales, celebrar los éxitos para generar confianza en el proceso, y organizar retrospectivas. 

Esta falta de mejora continua puede darse también porque los equipos sienten una sobrecarga de trabajo o por la falta de comunicación. Quizás las expectativas y prioridades son poco claras, se realizan demasiadas tareas a la vez o las tareas no se alinean con los objetivos estratégicos. Esto puede reducir la eficiencia, generar retrasos y estrés, pero además puede derivar en una pérdida del foco. Los equipos no entienden cómo contribuye su trabajo a los objetivos organizacionales, tienen demasiadas tareas porque estas no se han priorizado correctamente y falta tiempo para poder parar a analizar procesos. 

En estos casos es ideal limitar el trabajo en curso mediante reglas explícitas y revisiones regulares del tablero Kanban.

Actividades clave

Para garantizar que cada nivel funcione de manera óptima y esté alineado con los objetivos generales, Flight Levels propone cinco actividades esenciales:

• Visualizar la situación. Identificar qué trabajo está en marcha, los resultados obtenidos y los posibles obstáculos en los procesos.
• Centrarse en lo importante. Asegurar que las tareas prioritarias se ejecuten y entreguen, limitando el trabajo en curso y estableciendo prioridades claras.
• Establecer interacciones ágiles. Facilitar la toma de decisiones por parte de las personas adecuadas, en el momento oportuno y con la información necesaria.
• Medir el progreso. Definir qué significa progreso en cada nivel, ya sea mediante proyectos, OKRs, KPIs u otros indicadores, y monitorear el avance en la dirección correcta.
• Operar y mejorar. Repetir continuamente las actividades anteriores para adaptarse a los cambios y aplicar los aprendizajes obtenidos.

Flight Levels y AgiLevel

Flight Levels proporciona un marco claro para conectar la estrategia con la ejecución operativa. Sin embargo, no abarca los aspectos culturales y estructurales de la organización como AgiLevel.

AgiLevel analiza factores en la dimensión operativa, pero también en la dimensión organizativa (cultural y estructural) y en el soporte. Aborda elementos fundamentales como la cultura organizacional, la estructura jerárquica y la alineación con los principios ágiles.

Mientras Flight Levels pone el foco en mejorar los flujos de trabajo en niveles estratégicos, de coordinación y operativos, AgiLevel integra estos aspectos con la evaluación del contexto cultural, proporcionando una visión más holística. Es decir, Flight Levels facilita la visualización y optimización del trabajo en distintos niveles, y AgiLevel guía a la organización en un cambio más profundo.

La implementación de ambos enfoques no es excluyente. Flight Levels puede ser el punto de partida para alinear equipos y operaciones, mientras que AgiLevel actúa como una brújula estratégica para asegurar que las intervenciones estén alineadas con la cultura organizacional.

Flight Levels puede ser útil para conectar la estrategia con la ejecución diaria. Permite visualizar un panorama más amplio y mejorar continuamente el flujo de trabajo.

¿Está tu organización lista para despegar con Flight Levels? Si queréis profundizar más en el tema, os recomendamos el libro Rethinking Agile de Klaus Leopold. 

También os recomendamos el taller «AgiLevel Canvas» en el Club Agile. En él comprenderéis el modelo AgiLevel y aprenderéis a usar la herramienta AgiLevel Canvas, creada por Nicolás Escobar. Esta herramienta es útil para analizar y obtener una visión clara del estado actual del nivel de agilidad de una organización.

The post Flight Levels: agilidad desde las alturas appeared first on Blog.