Hola buenas!!

Recientemente, me he topado con algunos artículos con diversos enfoques sobre lo que podríamos denominar la crisis de confianza sobre la agilidad. Esto me ha hecho pensar en si esta supuesta “crisis de lo ágil” es recurrente o no; y a qué es debido. Y en las consecuencias que tiene en la confianza de las organizaciones respecto a las tendencias en innovación en la gestión de proyectos. La aplicación de la agilidad ha topado siempre con la jerarquía organizativa. O mejor dicho, con las formas de hacer tradicionales. Cambiar las formas de hacer en pro de la eficiencia no es una tarea sencilla. La resistencia, más frontal o más sutil, de las organizaciones como entidad siempre ha sido y será el caballo de batalla en toda transformación.

En todos esto hay una explicación que pretendo que sea muy sencilla, aunque corro el riesgo de quedarme sólo en la superficie:

Richard P.Feynman lo explica muy bien en su libro de memorias, que siempre recomiendo: “¿Está ud. de broma sr. Feynman?”. Un libro con este título ya explica muy bien la trayectoria de una persona notable en la historia.

Feynman habla de un tipo de resistencia al cambio que denomina como “Cargo Cult”. La explicación es algo extensa y está basada en una serie de eventos ocurridos durante las batallas del Pacífico en la 2º Guerra Mundial.

El Cargo Cult se resume como “que todo cambie sin que nada cambie”. Al aparecer nuevas tendencias organizativas, como puede ser todo el movimiento Agile, aplicaremos nomenclatura, roles, herramientas e incluso actividades. Pero no por ello estamos aplicando los beneficios que se pretenden obtener al implantar dicho marco. Todo ha cambiado. Aparecen Scrum Masters y Dailies. Pero nada ha cambiado. Las partes interesadas son inaccesibles y jerárquicas; y el valor de los productos no avanzan de la forma esperada.

Esto no va de personas individuales. Naturalmente que encontramos a la típica persona que es claramente resistente a cambiar su modus operandi actual. No va de personas como digo. Va de las propias organizaciones, que son resistentes a adaptar sus acciones y actitudes hacia el negocio y hacia los equipos, para dar espacio a estas nuevas tendencias.

Así tenemos, por ejemplo:

• Equipos “ágiles” que no realizan Review, porque son incapaces de mostrar nada de lo que han hecho. Porque no entienden que su trabajo no es una churrera de acciones técnicas, si no que debe ser una estrategia inteligente y auto-organizada para obtener valor.
• POs que no son Owners, más bién “escribientes” a lo sumo, de los deseos incontrolados del negocio. Y digo incontrolados porque, a falta de un Owner, nadie controla realmente el producto. Su conveniencia, su integración en un portfolio, su evolución a largo plazo y, sobre todo, su integración con el propio negocio.
• Partes interesadas (no usuarias) que no se implican, pero imponen cortapisas opacas, o se reservan un derecho a auditoria no negociado. Y que tensan el buen hacer de los equipos.
• Partes usuarias que no quieren saber nada del producto hasta su finalización; y que no participan junto al equipo en la obtención de un valor real y útil.
• Una esponsorización, que no ve el producto como un elemento vivo y, en cambio, constante; y que, por lo tanto, no promueven prácticas organizativas que ayuden a la adaptación continua y la innovación.

En este estado de cosas, un agilista en una organización así puede reaccionar de una forma no siempre beneficiosa hacia su propio rol. Por ejemplo:

1. Implantaciones de agilidad enfocadas a los equipos y a la operación. Obviando la propia organización
2. Adaptaciones o customizaciones de la agilidad a la “realidad” de la organización
3. Aparición de marcos de trabajo que incluyen la propia organización sin intentar cambiar nada

Respecto a la primera reacción. En organizaciones donde la dirección y las áreas de negocio no son accesibles, y posiblemente no comparten estas nuevas formas de hacer. Donde los proyectos tienen problemas en su gestión y ejecución. Intentamos resolver estos problemas atacando al mensajero (a los técnicos y las áreas de proyecto). Como si el problema únicamente fuera una “falta de método”. Que posiblemente sea cierto: Puede no haber método para la gestión y ejecución de proyectos en esa organización. Pero el problema no es sólo por falta de método. De hecho, han salido adelante muchos proyectos con el único método de un “project”. El problema principal es la falta de canales de comunicación entre quien pide y quien hace. Y no me refiero únicamente a “poder hablarse” Me refiero a asumir responsabilidades.

Respecto a la segunda reacción. Eso de adaptar a la “realidad” de la organización no es más que un pequeño subterfugio para “no tengo autoridad para cambiar nada”. Para cambiar algo en una organización se necesitan dos cosas:

1. Un sentimiento de urgencia. Las cosas van mal. Los proyectos no dan resultados. Las relaciones están tocadas. Ergo: Necesito cambiar
2. Autoridad. El CEO y, más importante que el CEO, todos los CXX han de apoyar el cambio y sus consecuencias. No hay cambio sin consecuencias. Algunas consecuencias son esperadas: La eficiencia mejora y es visible. Otras consecuencias son necesarias: La organización y su estructura deben cambiar para favorecer esa eficiencia por encima de la eficacia individual o departamental.

Y respecto a la tercera reacción. Algunas organizaciones incluyen capas de gestión supuestamente ágil para montar un complicado puente entre la jerarquía tradicional, que no va a cambiar, y los equipos, que sí lo van a hacer. Aparecen roles interpuestos que limitan la visión del Product Owner. Aparecen actividades para “coordinar” el proyecto con visión directiva. Aumentamos la complejidad para crear un entorno que tiene como objetivo aparente el entendimiento entre todas las partes, aunque probablemente lo que conseguimos es que nada cambie.

¿Y dónde está la solución?

La solución está en la reflexión sobre cuál debe ser nuestro papel como agiistas. Hemos de evolucionar en el sentido de que somos mucho más que “aplicadores de un marco de trabajo X”. Somos transformadores de la organización.

La agilidad ya ha demostrado su valía. Los números cantan. Ahora nos toca demostrar la nuestra. Para transformar una organización no basta con conceptos abstractos y certificaciones. Se requiere algo más. El mejor transformador es aquel que ha vivido en sus carnes aquello que desea transformar.