Uno de los problemas persistentes en las conversaciones sobre agilidad es la polisemia. "Autogestión", "autonomía", "empoderamiento" y "autoorganización" se usan a menudo como sinónimos, cuando en realidad describen fenómenos distintos con implicaciones muy diferentes. Richard Hackman ofreció una distinción que sigue siendo útil hoy: la diferencia entre un equipo que gestiona cómo ejecuta una tarea asignada y un equipo que tiene autoridad también sobre qué tarea ejecutar, para qué y dentro de qué condiciones organizativas. Hackman describió cuatro grados de autoridad de equipo, desde aquellos que solo ejecutan hasta aquellos que participan activamente en la dirección estratégica. La diferencia entre estos extremos no es de matiz: es cualitativa (Leading Teams, 2002).

En el universo ágil, el marco conceptual más utilizado para esta distinción es el que parte del trabajo de pioneros como Lars Kolind y del posterior desarrollo teórico vinculado a las organizaciones Teal de Frederic Laloux, aunque la articulación más operativa para el contexto español viene siendo la que propone AgiLevel. AgiLevel distingue cuatro niveles de autoorganización con criterios concretos: equipos dirigidos, donde los miembros solo tienen autoridad sobre la ejecución de sus tareas; equipos autogestionados, donde además gestionan el cómo dentro del marco del proyecto; equipos autodiseñados, que también configuran su propio modelo organizativo y marco de trabajo; y equipos autogobernados, que participan en decisiones de estrategia global.

Lo significativo de esta escala no es que un nivel sea mejor que otro en términos absolutos, sino que muchas organizaciones que se presentan como "ágiles" operan de facto en el nivel 1 o, en el mejor de los casos, en el nivel 2, mientras sus comunicaciones internas hablan de "equipos autónomos y empoderados". Esa distancia tiene consecuencias.

El mapa de decisiones: una prueba sencilla y reveladora

Existe una forma de hacer visible la brecha entre autogestión declarada y real que no requiere ningún instrumento sofisticado. Basta con hacer una lista de las decisiones que el equipo toma habitualmente y clasificarlas. Algunas preguntas orientadoras:

• ¿Puede el equipo rechazar trabajo que considera mal definido sin que eso tenga consecuencias relacionales o profesionales?
• ¿Puede cambiar su proceso interno sin pedir permiso?
• ¿Tiene influencia real sobre su composición?
• ¿Puede decidir qué herramientas utiliza?
• ¿Puede decir que no a un sprint goal impuesto desde fuera?

No hay respuestas correctas universales — el nivel adecuado de autonomía depende del contexto cultural y estratégico de cada organización. Pero sí es útil tener claridad sobre dónde se está realmente.

La mayoría de los coaches y scrum masters con experiencia reconocen el patrón: el equipo decide el color de los post-its, el nombre del tablero y la hora de la daily. Todo lo demás viene dado. Eso no es autogestión; es autonomía cosmética.

Por qué ocurre esto: tres mecanismos que erosionan la autonomía real

Conviene no reducir este fenómeno a mala fe o hipocresía organizativa. En la mayoría de los casos, la brecha entre autogestión declarada y real es el resultado de mecanismos sistémicos bien documentados.

• Inercia jerárquica. Las organizaciones que adoptan marcos ágiles no suelen rediseñar simultáneamente sus estructuras de poder. Los managers siguen existiendo, sus responsabilidades formales no cambian, y la cadena de aprobación permanece intacta. En ese contexto, la autogestión del equipo opera en el espacio que la jerarquía le cede, no en un espacio propio. Cuando ese espacio se reduce, la autonomía desaparece con rapidez. Dave Snowden, creador del marco Cynefin, lleva años señalando que las estructuras organizativas no cambian por decreto: los patrones de comportamiento real emergen de los incentivos, no de los valores declarados.
• Ambigüedad deliberada. Muchas organizaciones no hacen explícito qué puede decidir el equipo y qué no. Esto puede parecer flexible, pero en la práctica genera una autonomía frágil: el equipo toma decisiones en zona gris hasta que una de ellas genera fricción, y entonces descubre que ese espacio no era suyo. Jeff Gothelf y Josh Seiden (2021) señalan que la falta de claridad sobre los límites de autonomía es uno de los inhibidores más frecuentes de la experimentación y el aprendizaje en equipos de producto. Sin saber hasta dónde pueden llegar, los equipos se autocensuran.
• Presión del contexto. Incluso cuando los equipos tienen autonomía formal, los plazos imposibles, los stakeholders con acceso directo al equipo, o la cultura del "urgente" pueden reemplazar la toma de decisiones autónoma por la reacción continua. El equipo técnicamente puede decidir, pero no tiene el espacio cognitivo ni temporal para hacerlo con criterio. Esto conecta con lo que Teresa Torres documenta en Continuous Discovery Habits (2021) cuando describe equipos que, a pesar de tener mandato para el discovery, acaban ejecutando una lista de funcionalidades que alguien decidió por ellos porque "no había tiempo para hacer las preguntas correctas".

La confusión entre proceso y autoridad

Hay una trampa conceptual que merece atención específica: confundir la propiedad del proceso con la propiedad de las decisiones. Un equipo puede aplicar Scrum con toda su ortodoxia y aun así no tener ninguna autoridad real sobre lo que importa.

Scrum Guide (2020) describe a los developers como "las personas del Scrum Team que están comprometidas a crear cualquier aspecto de un Increment usable en cada Sprint" y les atribuye la responsabilidad de crear el sprint backlog y adaptar el plan diario. Pero en la práctica, cuando el product owner no tiene ningún margen real para priorizar, o cuando el scrum master no tiene influencia sobre las condiciones organizativas del equipo, Scrum se convierte en un ritual de gestión de la demanda, no en un sistema de trabajo autónomo.

Esto no es un fracaso de Scrum. Es el resultado de aplicar un proceso en una estructura de poder que no ha cambiado.

Autonomía e IA: una nueva capa de complejidad

Esta conversación ha adquirido una dimensión adicional que no podemos ignorar. La adopción acelerada de herramientas de inteligencia artificial generativa en los equipos de desarrollo, producto y diseño abre preguntas nuevas sobre la autonomía: ¿quién decide qué herramientas de IA puede usar el equipo?, ¿quién supervisa cómo se usan?, ¿dónde está el control humano en las decisiones que la IA co-produce?

La investigación emergente en este campo sugiere que las organizaciones con cultura de mayor autonomía están adoptando la IA de forma más efectiva, precisamente porque sus equipos tienen criterio propio para decidir cuándo y cómo usarla. En contraste, en organizaciones donde la autonomía es declarada pero no real, la IA tiende a gestionarse como otro elemento de cumplimiento normativo: se adoptan las herramientas que manda el proveedor o la dirección, sin que el equipo tenga voz en la decisión.

AgiLevel, en su dimensión organizativa, señala expresamente este punto: en contextos de agilidad avanzada, las herramientas tecnológicas — incluida la IA — deberían aplicarse respetando la autonomía de los equipos, con equipos que tienen la libertad de elegir la herramienta que mejor se adapte a su forma de trabajar. Esa no es una postura romántica sobre el empoderamiento; es una condición pragmática para que la adopción tecnológica genere valor real en lugar de fricción adicional.

Hacer visible lo invisible: un ejercicio práctico

Uno de los ejercicios más eficaces que pueden hacer equipos y coaches es lo que podríamos llamar un mapa de autoridad de decisiones. La mecánica es sencilla: durante una retrospectiva o una sesión específica, el equipo identifica las decisiones más relevantes de su trabajo cotidiano y las clasifica en tres categorías:

• Decisiones que tomamos con total autonomía.
• Decisiones que influenciamos pero que otros aprueban o vetan.
• Decisiones que nos comunican pero en las que no participamos.

El objetivo no es generar una lista de quejas, sino obtener una imagen honesta de la realidad actual. A partir de ahí, la conversación puede dirigirse hacia dónde querría estar el equipo, qué necesitaría para avanzar un paso en su autonomía y qué conversaciones habría que tener con la organización para lograrlo.

Esther Derby y Diana Larsen (2006) insistían en que la retrospectiva más poderosa no es la que genera una lista de acciones, sino la que consigue que el equipo vea su situación con mayor claridad. Este ejercicio apunta en esa dirección.

Lo que la organización necesita para que la autogestión sea posible

La autogestión no es una decisión que los equipos puedan tomar de forma unilateral. Requiere condiciones organizativas que dependen de niveles de la organización que el propio equipo no controla. Esto es importante reconocerlo para no caer en la trampa de culpabilizar a los equipos por una falta de autonomía que en realidad tiene causas estructurales.

Hackman identificó tres condiciones básicas para que un equipo pueda funcionar de forma real e independiente:

• una dirección clara sobre el propósito, sin microgestion sobre el método;
• una estructura de equipo que facilite el trabajo (no cualquier combinación de personas con cualquier conjunto de tareas);
• y un contexto organizativo que proporcione los recursos, la información y el apoyo que el equipo necesita para funcionar.

Cuando alguna de estas condiciones falta, la autonomía se convierte en responsabilidad sin recursos, lo que es exactamente lo contrario del empoderamiento.

En términos de diagnóstico organizativo, esto se refleja también en cómo AgiLevel evalúa la agilidad organizativa: la autoorganización real requiere que las personas dispongan de información, autoridad y confianza para tomar decisiones autónomas. Los tres elementos son necesarios; la ausencia de cualquiera de ellos limita la autonomía efectiva. Un equipo que tiene confianza pero no información no puede decidir bien. Un equipo que tiene información pero no autoridad no puede actuar. Un equipo que tiene autoridad pero no confianza experimentará esa autoridad como una trampa.

La pregunta que vale la pena hacerse

Si trabajas como scrum master, agile coach o líder de equipo, hay una pregunta que merece reflexión honesta: ¿cuándo fue la última vez que tu equipo tomó una decisión importante que tú (o alguien por encima de ti) habrías tomado de forma diferente, y esa decisión se respetó?

No se trata de que el equipo siempre tenga la razón. Se trata de que la autonomía real se prueba precisamente en los momentos de desacuerdo, no solo cuando el equipo decide lo que la organización habría decidido de todas formas. Un equipo que siempre coincide con lo que la organización habría hecho probablemente no está ejerciendo autonomía real: está adivinando correctamente lo que se espera de él, que es una habilidad distinta y, en términos de aprendizaje organizativo, mucho menos valiosa.

Henrik Kniberg señaló algo que sigue siendo relevante: la autonomía sin alineación es caos, pero la alineación sin autonomía es burocracia disfrazada de agilidad. El equilibrio entre los dos no es estático; requiere trabajo continuo de calibración.

La autogestión declarada tiene un efecto secundario que rara vez se discute: cuando los equipos saben que tienen "autonomía" pero experimentan que sus decisiones importantes son revertidas o ignoradas, el resultado no es neutral. La investigación de Edmondson sobre seguridad psicológica muestra que la percepción de pseudoautonomía es uno de los factores que más erosionan la motivación y la seguridad psicológica de los equipos. No es solo una cuestión de eficiencia operativa; afecta a la capacidad de las personas para comprometerse con su trabajo.

Esto no significa que toda organización deba apuntar al nivel máximo de autonomía. El nivel adecuado depende de la madurez del equipo, de la cultura organizativa y del tipo de trabajo que se realiza. Lo que sí parece claro es que la distancia entre lo que se declara y lo que se practica tiene un coste, y que ese coste vale la pena medir antes de seguir invirtiendo en transformaciones que en la práctica no están cambiando lo que más importa.

Si quieres tener una imagen más precisa de dónde está tu organización en términos de autonomía real el radar AgiLevel ofrece un diagnóstico de doble dimensión (prácticas operativas y valores culturales) que puede ser un buen punto de partida para esa conversación.

¿Cuántas decisiones toma realmente tu equipo? ¿Cuántas te gustaría que tomara? Y si hay distancia entre las dos respuestas, ¿qué la explica?

Bibliografía

• Edmondson, A. C. (2018). The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth. Wiley.
• Derby, E. y Larsen, D. (2006). Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf.
• Gothelf, J. y Seiden, J. (2021). Lean UX: Designing Great Products with Agile Teams (3ª ed.). O'Reilly Media.
• Hackman, J. R. (2002). Leading Teams: Setting the Stage for Great Performances. Harvard Business School Press.
• Kniberg, H. y Ivarsson, A. (2012). Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds. Recuperado de https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf
• Laloux, F. (2014). Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage of Human Consciousness. Nelson Parker.
• Mollick, E. (2024). Co-Intelligence: Living and Working with AI. Portfolio/Penguin.
• Torres, T. (2021). Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value. Product Talk LLC.
• Schwaber, K. y Sutherland, J. (2020). The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game.
• Scrum Manager / AgiLevel. (2024). AgiLevel: Diagnóstico de agilidad organizativa. Scrum Manager.
• Snowden, D. y Boone, M. E. (2007). "A Leader's Framework for Decision Making". Harvard Business Review, 85(11), 68–76.