Agile Team II: Storming. Navegando en el conflicto

Los equipos que se formaron hace poco, van pasando juntos tiempo. Los individuos van interactuando entre ellos, se van conociendo y van estableciendo relaciones interpersonales. Se van produciendo distintas situaciones donde se puede ver como los miembros del equipo responden a las éstas. Y tal y como reza el título de la serie de los 80 donde se cuenta las aventuras y desventuras de la familia Seaver, “Los problemas crecen”.

NOTA: Entendiendo problema desde su definición más filosófica como algo que altera la paz, el equilibrio y la armonía de quien o quienes lo tienen. En términos más mundanos, hablamos de una circunstancia que dificulta la consecución de algún fin.

Storming, ¿qué es?

Es cuestión de tiempo, todos los equipos tardan más o tardan menos, pero todos acaban evolucionando. Según el modelo de Tuckman la siguiente etapa evolutiva de un equipo es el estado de Storming, o como se ha traducido por algunos autores “Conflicto”.
Con el paso del tiempo, ya existe la suficiente confianza entre los miembros del equipo, y empiezan a expresar sus diferencias respecto las acciones y opiniones de los otros miembros del equipo.

Teníamos un equipo con gente de distintos departamentos que están enfrentándose a situaciones de presión. Es muy habitual en esta etapa que se produzcan conflictos entre los miembros del equipo. Un síntoma inequívoco que un equipo está en fase de Storming pueden ser comentarios tipo “no hemos acabado la US porque QA no ha acabado”, “los Developers no hacen los tests unitarios y por eso no llegamos”, etc.

A pesar de ser oficialmente un equipo, no son más que un grupo de individuos. Siguiendo con el símil futbolístico, aquí podríamos escuchar comentarios tipo: “Si todos tuvieran mi nivel, estaríamos primeros” o “Al equipo le doy un 9 y a mí, un 10”, jugadores que anteponen su bien personal al grupal.

Esta etapa es necesaria. No habrá equipo que perdure en el tiempo que no se haya encontrado en ella. Si se quiere llegar a un equipo de “alto rendimiento” es necesario que los miembros del equipo muestren sus diferencias.

El papel de Scrum Master

En esta fase es fundamental el papel del Scrum Master, su cometido es “guiar al Equipo de Desarrollo en ser autoorganizado y multifuncional”, tal y como se describe en la guía Scrum. En esta fase tan crítica, deberá actuar mediante el ejemplo y como líder servicial, deberá ser el modelo a seguir, “tirando del carro” para que el resto de quienes forman el grupo tomen conciencia y asuman sus responsabilidades.

De hecho, lamentablemente, éste es el estado natural de muchos equipos. Dónde siempre la culpa es de los demás miembros/silos con los que interactúan en la cadena de valor. Sin embargo, cuesta mucho de verlo, puesto que siempre ha sido así, con rivalidades entre departamentos, aunque el trabajo de todos ellos influya en el resultado final.

Si volvemos al ámbito futbolístico, tenemos delanteros quejándose que los defensas encajan muchos goles, ¡defensas acusando a los delanteros de no estar comprometidos en presionar o bajar a defender y al pobre portero diciendo “es que me dejáis sólo!”. Se pierden partidos y “la culpa es siempre de los otros miembros del equipo”.

Es muy importante durante esta etapa, el equipo Scrum y sobre todo el Scrum Master, sean capaces de mantener los conflictos que afloren en el equipo, bajo control. Ayudando al equipo a comunicarse y que aprendan a colaborar entre ellos mediante la creación de un entorno de confianza y colaboración para que todos los miembros del equipo puedan poner en común sus opiniones y avanzar juntos en la identificación y resolución de conflictos.