Miedo a la libertad / Fear of freedom

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.

The other day I heard a psychologist explain how the history of mankind, from a sociological point of view, is defined by alternating movements: respectively, tendencies demanding more freedom and tendencies “asking” for more control. After times of unusual freedom, humanity seems to opt for dictatorship. The explanation struck me: confronted with a feeling of freedom we are not used to, we feel a need to be controlled and have the relief of having others make decisions for us.The liability associated with our freedom overwhelms us.

I thought of a problem that sometimes appears when introducing agile methodologies. The team has a sense of having more freedom, more responsibility, as opposed to being in a typical "hierarchy" where the technical lead or project manager is telling you what to do and how to do it, at all times. Self-managed teams. Is everyone happy? On the contrary.

Often, team members are scared. They don’t feel comfortable not only with the change (the fear of change can, and will, inspire another blog entry!), but also with this new freedom. Listen to the psychologist talk about the fear of freedom made me realize that it is a well-founded fear, rational, and should not be neglected.

When fear is deeply rooted in the consciousness of each, thinking that a couple of sentences in a team presentation will solve the problem is a large error (error that, however, I have seen many times). “We'll all be agile - and you will see how cool it is!” It does not work like that. We must make continued efforts, tracking each team member’s progress. Help them to gradually take responsibility. Each person is different, and one of the most common problems is to obviate this and treat the team as a "whole" in the delicate matter of changing the way we work.

One technique that works well is to have one-to-one meetings with each team member, regularly. It is not worth skipping them because everything seems to go well or because of a heavy workload, especially in the early stages of change. If the SCRUM Master is also the project manager (i.e., the immediate boss), this case is ideal, because you usually have meetings one-to-one. You also have the authority to make decisions if they become necessary.

But we all know that the SCRUM Master is not always the project manager, and, moreover, many times it should not be. In this case, you should have another meeting between the SCRUM Master and every member of the team, because in the typical one-to-one with the boss, the SCRUM Master will be left out. A meeting so the SCRUM Master can understand each person’s fears about change, see particular situations in which they felt quite depressed, etc.

Finally, just say that another major problem I encountered when introducing SCRUM is peer pressure. The typical example could be one like follows: “Everybody seems so happy to work agile! I am not, but I don´t dare to make it public during a meeting with the team as I do not want to be accused of being waterfall!". This is another good example of why the one-to-one(s) are so important, because in these conversations, people don’t feel peer pressure and we can solve more problems.