A estas alturas de la película prácticamente todos estamos familiarizados con la figura del Scrum Master en los equipos. Sin embargo, tengo la sensación de que cuanto más se asume su presencia, menos claras se tienen sus competencias, los cometidos tangibles por los que poder evaluar o medir su trabajo, más allá de los resultados. Y ello, tirando un poco de autocrítica, quizá sea debido, entre otros factores, a que de un tiempo a estar parte parece que hemos puesto más énfasis en recordar lo que no hacemos que en exponer claramente lo que podríamos -o deberíamos poder- ofrecer.
En este post intento establecer una correlación de técnicas y valores que, dentro del agilismo, pueden aplicarse y fomentarse para intentar paliar “Las 5 disfunciones de un equipo” (2002), diagnóstico certero de Patrick Lencioni de algunas de las causas por las que un equipo puede no saber o querer funcionar como tal, rindiendo por ende por debajo de lo esperado. Disfunciones, por lo común, tan intrincadas con los sentimientos y emociones personales que exigen un espacio de reflexión interna, por lo que invito al lector a identificarse y reconocerse en su propio equipo, sea Scrum Master o no. De ahí el título del post, clickbaits aparte.
DISFUNCIÓN 1: La ausencia de confianza
Que la confianza es la base de todo equipo parece casi una obviedad. Sin embargo, son muchos los equipos cuyos miembros no tienen la confianza suficiente para decir lo que piensan. Además, cuando uno no tiene confianza con alguien es más probable que tomemos como un ataque cualquier apreciación.
Lo ideal es que los integrantes de un equipo adquieran confianza a través de rutinas que, generalmente, suelen surgir de manera natural, como pueden ser desayunar y/o comer juntos o unas cañas tras el curro. Estos hábitos saludables encuentran leve obstáculo en equipos en remoto y mayor en casos aislados de misantropía, pero igualmente no viene mal un refuerzo inducido en según qué situaciones, aunque con cuidado. Porque probablemente no haya nada que genere mayor incomodidad y desconfianza que sentirnos obligados a abrirnos frente a un grupo.
Las dinámicas que inciden en este punto suelen ser o bien de autodefinición (desde un Personal Mapping a una Matriz de Habilidades, si nos queremos poner más técnicos) o bien de descubrimiento del otro mediante preguntas y respuestas o Team Buildings varios. Ojo con esto: un Team Building quizá sea la manera más intrusiva de intentar estrechar lazos, suelen acogerse con recelo y es complicado que satisfagan a todos. Aunque se puede recurrir a ellos como refuerzo positivo, a modo de celebración, siempre de manera voluntaria y en horario laboral a ser posible. Particularmente, pienso que la manera más sutil es la revelación de sentimientos a partir de la abstracción (Cartas Dixit) y la representación (Lego) de situaciones: una imagen o una figura que simboliza nuestro estado anímico como punto de partida para ahondar en ello.
En cualquier caso, la responsabilidad del Scrum Master en este campo es la de propiciar un entorno que ayude a romper estas corazas, donde no tengan cabida las actitudes coartantes e intransigentes, se eviten las culpas individuales a toda costa e impere la humildad para preguntar todo aquello que no se sepa. Fomentar la vulnerabilidad, lo llaman.
DISFUNCIÓN 2: Miedo al conflicto
Los equipos cohesionados y realmente productivos discuten. Discuten mucho. O, al menos, deberían. Un equipo que no tiene una discusión encendida sobre alguna cuestión técnica u organizativa es un equipo pasivo, alienado, que raramente va a marcar una diferencia sustancial.
Pero para discutir bien, lo primero de todo sería aprender que el conflicto es muy diferente de la agresión. Y no me refiero explícitamente a caer en el insulto o la descalificación. Esto que suena tan trivial, no todo el mundo es capaz de hacerlo. Por ello, es necesario establecer unas reglas de equipo que respeten sus propios códigos internos y fijen unos límites para que, un supuesto moderador pudiera levantar la bandera roja una vez se franquearan.
El segundo punto a aprender es que un conflicto resulta generalmente doloroso, sobre todo si hemos reforzado la confianza mutua. Dos personas que no se importan discutirán en modo agresión más fácilmente que dos que se estiman y respetan. Pero también nos veremos más afectados. Hay técnicas para identificar cómo se discute (Thomas-Kilmann Conflict Mode Instrument), porque a veces uno no es consciente del todo de cómo lo hace o quizá quisiera discutir de otra manera. De todos modos, con confianza uno podrá manifestar al otro sin problema si se ha sentido herido.
Por otro lado, el foro para tratar los problemas del equipo es la Retrospectiva. De un tiempo a esta parte la Retrospectiva se ha convertido en el espacio de lucimiento personal del Scrum Master, el momento en el que pareciera ha de justificar su trabajo haciendo gala de un derroche de fantasía e imaginación… Y no. Las retrospectivas no tienen por qué ser ni imaginativas, ni divertidas, tienen que ser, ante todo, efectivas. Y para que una Retrospectiva sea efectiva, tiene que haber conflicto, dolor y, por ende, cohesión. Salir cabreados, exhaustos o motivados… Y con tarea a cuestas, objetivos SMART (Specific, Measurable, Attainable, Relevant, Time bound) a implementar.
La premisa es romper esa falsa armonía llena de tensiones internas que acaba por explotar justo cuando menos se necesita: ante la adversidad.
DISFUNCIÓN 3: Falta de compromiso
El mercenario del código, que diría mi colega Héctor López: tiro mis líneas, me exijo lo mínimo posible y cumplo con el expediente. Sería muy aventurado decir que la falta de compromiso viene únicamente motivada por el hecho de no sentirse implicado, pero desde luego que puede ser un factor que lo incentive. Y esa falta de implicación a menudo viene propiciada por la toma de decisiones.
De entre los distintos modelos de toma de decisiones está claro que (¿casi?) todo el mundo diría que el autocrático no es el bueno y que lo mejor sería el consenso, pero todo tiene su lugar. La votación, tanto por mayoría absoluta como por mayoría simple es la forma más extendida y no necesariamente la más acertada, puesto que suele crear bandos y a menudo se emplea de manera que no contempla argumentación posible para la parte perdedora. La forma idílica sería el consenso, sí: todos de manera madura llegamos a un acuerdo. Sin embargo, puede dilatarse demasiado en el tiempo y generalmente no disponemos de tanto margen de maniobra (recordemos que el Agilismo permite tomar decisiones rápidas, puesto que permite fallar en el proceso). Una forma menos conocida y más apta para según qué decisiones sería el consentimiento: un acuerdo de mínimos. O lo que es lo mismo, estando en desacuerdo, qué no nos rasga las vestiduras, hasta dónde podríamos ceder.
Independientemente del modelo de toma de decisiones empleado, lo importante para evitar la falta de compromiso es contemplar las opiniones de cada uno. Si sentimos que algo nos ha venido impuesto, raramente nos vamos a comprometer con ello. Especialmente si estamos en desacuerdo, que es de lo que se trata.
DISFUNCIÓN 4: Exención de responsabilidad
Fruto de la falta de compromiso surge la exención de responsabilidad, algo que juega en dos direcciones: En que si algo con lo que no estábamos de acuerdo falla, no aceptamos responsabilidad alguna sobre ello. Pero también en que no nos inmiscuimos en lo que el otro está haciendo y nos centramos únicamente en nuestra parcela, que es la que nos parece bien. Es más, es probable que ni siquiera sintamos que el plan ha fallado, porque muy probablemente no consideremos el plan como algo nuestro.
Para ello hay que elaborar estándares que apliquen al equipo, de tal manera que uno no pueda tener éxito sin el éxito común. Esto pasa por hábitos ya asumidos de XP tales como la revisión de código activa, el CI/CD o el establecimiento de estándares de calidad y rendimiento. Pero más importante aún son las métricas colectivas, que son las que van a marcar el éxito o fracaso de la iniciativa. Para ello, es preciso sentarse con el PO y elaborar una serie de áreas y puntos a medir recurrentemente para contemplar su evolución.
La clave, en definitiva, es establecer una exigencia común que permita definir éxitos o fracasos colectivos en detrimento de los individuales.
DISFUNCIÓN 5: Pérdida de foco
La quinta disfunción no es más que la mera conclusión de todo lo demás, la ausencia de foco. Vamos como pollos sin cabeza. Ante la no existencia de un objetivo común, cada uno hace la guerra por su lado, y al entregar su parte considera que el trabajo ya está hecho.
Es básico tener bien a la vista un roadmap del producto. Pero, y esto a muchos les va a sorprender, sobre todo cuando hablamos de un entorno Agile, es beneficioso, necesario y realista disponer de fechas que marquen el ritmo y las expectativas. Estas fechas han de ser obviamente lo suficientemente amplias y consensuadas, pero han de existir y forzar nuestro umbral. Lo contrario es tan irreal como desmotivante.

Resumiendo: la ausencia de confianza propicia el miedo al conflicto, que a su vez se traduce en falta de compromiso. Esta falta de compromiso tiende a favorecer que se eludan responsabilidades, por lo que se pierde el foco, el objetivo común. Como vemos, realmente hay una correlación clara de valores como pueden ser los de Scrum en este caso y las disfunciones que queremos evitar. En general, serían aplicables a cualquier entorno de trabajo que pretenda ser mínimamente funcional, en el que la gente trabaje en equipo y sus opiniones sean consideradas y no se frustre por lo contrario y esté motivada y comprometida y produzca más y mejor, que es lo que realmente importa en este Humans of Late Capitalism Agile.
Y, un poco relacionado con todo esto, como colofón, están los sentimientos, las emociones propias. Os invito a que cada vez que sintáis uno de los mal llamados sentimientos negativos, como puede ser la ira, la tristeza o el miedo… Os paréis a reflexionar qué es aquello que lo ha provocado. Pero no el hecho concreto en sí, sino lo que subyace detrás. Si me he sentido despreciado, amenazado, decepcionado… el porqué. Para así, con esta reflexión, poder acudir al compañero en este caso y abordar la cuestión con coraje y respeto hacia uno mismo y los demás.

PD: Aquí una formación que impartí en Paradigma con este contenido.
Inspiraciones:
- The 5 Dysfunctions of a Team (Patrick Lencioni, 2002)
- La Guía de Scrum (Ken Schwaber y Jeff Sutherland, 2010)
- SMART Goals. How to Make Your Goals Achievable (2016)
- Cómo medir el éxito de una transformación Agile con EBM (Fco. Javier González, 2019)
- Métodos de toma de decisiones (Esther Estévez, 2019)
- Thomas Kilmann Conflict Mode Instrument (Kenneth Thomas y Ralph H. Kilmann, 1974)
- En contacto íntimo (Virginia Satir, 2008)
- Inside Out (Pete Docter y Ronnie Del Carmen, 2015)
- Agile Retrospectives – Making Good Teams Great (Esther Derby y Diana Larsen, 2012)
- Agile Antipatterns (Matthew Reinbold, 2019)
Un comentario en “Cómo tu Scrum Master puede remediar las 5 disfunciones de un equipo”