Miedo a la Libertad

El otro día oí a una psicóloga explicar que la historia de la humanidad, desde un punto de vista sociológico, viene marcada por alternancias de movimientos que, respectivamente, reclaman más libertad del pueblo o “piden” más control. Después de épocas en las que florecen las libertades, el género humano parece decantarse por regímenes dictatoriales. La explicación ofrecida me llamó la atención: ante una libertad a la que no estamos acostumbrados, sentimos una necesidad de control, un alivio al dejar que se tomen las decisiones por nosotros. La responsabilidad asociada a nuestra libertad nos abruma.

Pensé en un problema que aparece a veces en los equipos en los que se introduce una metodología ágil. El equipo experimenta una sensación de más libertad y de más responsabilidad que en un típico grupo “jerárquico” donde el líder técnico o el gestor de proyecto te dicen qué hacer y cómo hacerlo en todo momento. Equipos auto-gestionados. ¿Todos contentos? Al contrario.

Muchas veces los miembros del equipo se asustan. No se sienten cómodos, no sólo con el cambio (¡el miedo al cambio podría y seguramente inspirará otra entrada!), sino también a la novedosa libertad. Escuchar a la psicóloga hablar del miedo a la libertad a nivel sociedad me hizo darme cuenta de que es un miedo fundado, racional, que no debe ser despreciado.

Cuando se trata de miedos muy arraigados en la consciencia de cada uno, pretender que con un par de frases en una presentación de equipo se van a solucionar es un gran error (error que, sin embargo, he visto muchas veces). “Vamos a ser todos ágiles – ¡veréis qué bien!”. No; hay que hacer un esfuerzo continuado, de seguimiento, de cada miembro del equipo. Ayudarles a que vayan tomando responsabilidades de forma progresiva. Cada persona es un mundo y uno de los problemas más habituales es obviar esto por falta de tiempo y tratar al equipo como un “todo” en la delicada materia de cambiar la forma de trabajar.

Una técnica que funciona bien es tener con cierta regularidad reuniones one-to-one con cada miembro del equipo. No vale ahorrárnoslas porque todo parece ir bien o por demasiado volumen de trabajo; y sobre todo en las primeras etapas del cambio. Si el SCRUM Master es el gestor del proyecto (o sea, el jefe inmediato), este caso es ideal, porque ya se suelen tener reuniones one-to-one. Además, tendrá la autoridad para tomar decisiones si llegan a ser necesarias.

Pero todos sabemos que el SCRUM Master no siempre es el gestor del proyecto, es más, muchas veces es aconsejable que no lo sea. En este caso, debería hacerse otra reunión de frecuencia variable con el SCRUM Master, porque en el típico one-to-one con el jefe el SCRUM Master quedará fuera. Una reunión para que el SCRUM Master pueda entender, persona a persona, sus miedos respecto al cambio, las situaciones particulares en las que se sintieron demasiado presionados, etc.

Finalmente, mencionar que otro problema importante con el que me he topado al introducir SCRUM es la presión del grupo. El típico ejemplo: ¡todo el mundo parece tan encantado de trabajar ágilmente! Algún miembro tiene sus reticencias, pero no se atreve a hacerlas públicas durante una reunión con todo el equipo por la famosísima presión del grupo o peer pressure: “No quiero que me tachen de waterfall”. Otro buen ejemplo de porqué las reuniones one-to-one son tan importantes es porque en estas conversaciones es cuando se desenmascaran los miedos de cada uno y se pueden solucionar los problemas.