Las siete alarmas internas que el Scrum Master debe escuchar

Los ojos y los oídos del Scrum máster deben estar siempre al acecho. Sabemos que debe tener una actitud observadora y atenta hacia todo lo que sucede durante el día a día del equipo de Scrum, sin embargo esa actitud no debe percibirse como controladora como quizás daría un jefe de proyecto más tradicional, o amonestadora como haría un árbitro soplando el silbato cada vez que no se cumple una norma.

La actitud correcta debe desprender aire de compañerismo, de cercanía, de servidumbre desinteresada. Algo como “Soy parte del equipo y mi labor aquí es en primera instancia por y para vosotros y por el producto.” Ser invisible durante la mayor parte del tiempo y hacerse visible en los momentos que lo requieran.

¿Pero qué momentos son esos? ¿Cómo los detectamos?

A continuación os dejo una lista de algunos momentos en los que la alarma interna del Scrum máster debe saltar. Aunque existen muchos más momentos provocados por agentes externos en este artículo me he querido centrar en los más difíciles: Aquellos que dependen exclusivamente del Scrum máster, o dicho de otro modo, las alarmas propias del portador del rol.

Alarma 1: No proteger el proceso.

El scrum master es el guardián del proceso. A veces se le describe como el ‘Process manager’ e incluso se le da calidad de gestor en ese aspecto. También conoce bien la guía de Scrum, los fundamentos sobre los que se asienta (empiricismo), valores, pilares y todos los elementos esenciales que constituyen Scrum como un framework de trabajo.

Existen algunos elementos que no son obligatorios, por ejemplo el uso de burn-downs, las tres preguntas del daily, sesiones de refinamiento o el uso de métricas como la velocidad del sprint. Sin embargo otros son indispensables: Los tres roles, los tres artefactos, los cuatro eventos además del Sprint como tal y las propias reglas del juego.

Esta alarma debe sonar en la cabeza de cualquier SM cuando se propongan cambiar las reglas del juego (ejemplo: extender un sprint a más de un mes de duración) o se omitan partes del framework (ejemplo: no hacer una retrospectiva, se decida no tener un SM al uso, etc).

Si no es el SM el que pone freno a estas circunstancias entonces nadie lo hará (tenlo por seguro), el equipo acabará haciendo algo parecido a Scrum que no es Scrum y todos sus beneficios estarán perdidos.

¿Cómo actuar? Aquellos que quieren cambiar cosas no lo hacen generalmente con mala intención sino por desconocimiento. Aprovecha cada oportunidad para explicar por qué ese elemento no debe omitirse o cambiarse y haz entender en el momento que las normas están ahí por algo. Para eso debes de ser capaz de explicar in-situ breve pero determinantemente cualquier elemento del framework de scrum, y por supuesto, defenderlo a capa y espada. (Quizás no te haga falta una capa pero la espada…)

Alarma 2: No escuchar

Aunque es aplicable a cualquier rol, en general el SM no puede ser esa persona que a veces escucha y a veces no. Cuando un miembro del equipo viene y le comenta algo no puede permitirse el lujo de tener la mente en otra parte y actuar de forma condescendiente. Cuando lo hace está perdiendo información importante y también la oportunidad de que dicha conversación o momento se vuelva a repetir (es probable que no se vuelva a repetir). No escuchar tiene consecuencias malas, por ejemplo, puede llevar a asunciones erróneas, el SM puede determinar que lo que escucha no es un impedimento cuando sí lo es y viceversa, o perderse la calidad de las interacciones DT-PO, DT-Stakeholders.

¿Sabías que existen hasta tres niveles de escucha? Hacerlo bien es difícil y se trata de una habilidad que se puede desarrollar.. Requiere un esfuerzo. No escuchar minimiza uno de los valores fundamentales de Scrum: el enfoque. En la próxima conversación en la que no estés al 100% atento o en el próximo daily scrum en el que tu mente divague date una bofetada (mental) y vuelve al planeta tierra. 

Alarma 3: Juzgar

Se trata de algo que hacemos todos de forma natural: Juzgamos, valoramos y creamos opiniones en base a lo que vemos y oímos. El equipo juzga continuamente, deben discutir las opciones considerando los puntos de vista de todos los miembros para tomar la decisión más acertada posible. El Scrum Máster no debe unirse a esta actividad de manera directa. Cualquier discusión técnica es de dominio del equipo. Es más, cualquier discusión no técnica (por ejemplo personal) también es dominio del equipo (Recuerda que ellos son auto organizados) y si el Scrum máster media en ello debe hacerlo desde la mayor neutralidad posible de modo que por su propio pie puedan alcanzar una solución.

Cuando juzgas obligas al equipo a posicionarse alrededor de tu juicio y eso condiciona el resultado. Si el Scrum master es además alguien respetable entonces un simple gesto de (des)aprobación puede cambiarlo todo. La obligación del scrum máster es hacer entender al equipo qué interacciones son buenas o malas para el equipo, y esto incluye las tuyas propias.

Por lo tanto, cuando esto ocurra intenta dejarlo dentro, no lo exteriorices. Cara de póker y en tu mano dispón las cartas de la apuesta ganadora: ¡Ellos! 

Alarma 4: Romper el silencio

Los silencios son importantes. Anuncian que deben romperse si el equipo quiere seguir adelante y tienen la característica especial de que son incómodos si duran demasiado tiempo. También indican que el equipo necesita un pequeño espacio para pensar y ofrecer una solución o valoración con lo que no importa quien tras una pregunta de cierto calado origine un silencio; el SM debe hacer lo posible por no ser él quien lo rompa.

Es más, una de las armas más potentes del scrum máster es hacer preguntas que originen silencios, preguntas realmente influyentes que hagan al equipo Scrum reflexionar y recapacitar.

Sabrás que has hecho una cuando detrás de ella venga un silencio largo e inquietante. Luego aguarda el tiempo necesario. Alguien intervendrá.

Alarma 5: Sobreproteger al equipo

Bien es sabido que el scrum máster es el protector del equipo. Previene por todos los medios que durante el tiempo de desarrollo de un sprint éste sufra distracciones que puedan retrasar el trabajo y poner en peligro el sprint goal. Por lo tanto no proteger al equipo es algo malo, pero sobreprotegerlo sigue siendo igual de malo.

Una manifestación de esta sobreprotección sucede cuando el Scrum Máster evita el fallo del equipo de desarrollo. Cuando digo fallo no me refiero a ‘fallar un sprint’ en el sentido de que no se completó todo el trabajo, sino más bien fallo en el compromiso del equipo en cuanto a generar un incremento usable y funcional al final del sprint con un valor para los stakeholders asociado. Recuerda que es su responsabilidad como equipo comprometerse a la entrega de valor. El SM puede ver el fallo avecinarse y hacer las preguntas influyentes adecuadas. Si a pesar de ello el equipo no toma medidas por su propio pie, no prevengas que el fallo suceda. Esto también puede ocurrir con respecto al rol de Product Owner. Si el PO no hace bien su trabajo y el Scrum máster acaba por sustituirle en sus funciones (entablar contacto con stakeholders, manejar el product backlog, decidir cuándo efectuar una subida a producción, etc) entonces pasan dos cosas: La primera es que el SM es un proxy del rol de PO para el que probablemente no esté preparado. La segunda es que cualquier lección para el PO sobre cómo hacer su trabajo se habrá perdido y la situación sigue sin cambiar para el siguiente sprint.

Scrum mantiene periodos muy cortos de tiempo en los que los fallos se hacen transparentes y se contemplan, no se tapan. Por desgracia el fallo suele ser el mejor profesor en la mayoría de las circunstancias. Aprendemos y nos adaptamos. Regla de oro.

Otra manifestación de esta sobreprotección es evitar el conflicto. Generalmente tenemos la idea de que el conflicto entre miembros del equipo trae más problemas que beneficios, pero sin un mínimo conflicto no existe el cambio. Evidentemente hay grados de conflicto, pero un buen equipo de Scrum tiene que sentirse cómodo expresando sus ideas aunque sean opuestas, dispares o aunque generen divergencia en la toma de decisiones. No se trata de ver quién tiene más razón, recordemos que el equipo es uno, único, y finalmente deben consensuar todas las decisiones a pesar de que algunos miembros no estén totalmente convencidos.

El scrum máster ayuda al equipo a navegar por el conflicto, a diverger para después converger en una decisión común. Al  evitar conflictos no constructivos estará mermando la capacidad del equipo de mejorar por sí mismo y no dejandoles entender que discutir por encontrar la mejor solución es algo que está bien.

Alarma 6: Convertirse en el solucionador de problemas.

Este es en mi opinión uno de los pecados capitales del Scrum Máster.

Si el problema es un impedimento: ok, es dominio del scrum máster y debe trabajar para solucionarlo. (Ojo, un impedimento es algo que se sale del ámbito de actuación del equipo de trabajo y que no puede resolver por sí mismo).

Si no es un impedimento es dominio del equipo de trabajo. Punto.

El scrum master no es un team leader. No dice qué debe hacerse ni cómo debe hacerse, ni tampoco asigna trabajo a los miembros del equipo. Esto es fruto de la metodología tradicional en la que existe un director del trabajo que organiza ‘recursos’ y nada tiene que ver con el enfoque ágil en el que nadie excepto ellos mismos puede realizar esa tarea auto organizativa. En mi opinión el Scrum máster, si no tiene capacidad dentro del equipo de desarrollo como miembro (esto es, también hace labores de trabajo como un rol híbrido), no debe intervenir si no es por las razones adecuadas. En este hilo expongo el caso en el que el scrum master no trabaja como miembro y se le requiere para realizar trabajo como tal y completar así el sprint a tiempo. ¿Debería ayudar al equipo en ese sentido?

Alarma 7: Ser el portavoz del equipo

Derivado del anterior punto, se tiene cierta tendencia a creer que el Scrum master es el director del trabajo y el que cuando llega el momento de celebrar un evento de scrum debe tomar el micrófono y conducir la reunión. Nada más lejos de la realidad.

El scrum máster sí enseña al equipo, PO y stakeholders los puntos que deben cubrirse en cada reunión, sobre todo durante los primeros sprints, donde debe quedar claro el objetivo de las mismas. El planning debe constar de una estructura doble, tal como dicta la guía de scrum, donde debe forjarse un sprint goal y debe crearse un sprint backlog a partir del product backlog. Durante el review el Scrum máster no tiene apenas intervención pero sí tiene una labor fundamental de escucha y observación de las interacciones que posteriormente analizará con todo el equipo. La retrospective sugiere una intervención más directa del Scrum máster donde tiene más margen para tomar la iniciativa y exponer los problemas y mejoras que deben tomarse en cuenta a futuro, no obstante y a pesar de ello no lidera la reunión en su totalidad.

Tanto para el punto anterior como este existe ejercicio que consiste en hacerse redundante. Imagina que pasaría si en el próximo sprint no estuvieras presente como Scrum máster. ¿Te necesitarían para organizar el trabajo? ¿Para conducir el Daily? ¿Para ‘introducir’ el sprint review? ¿Para hablar con el PO acerca de una historia poco clara?... Cuanto menos necesiten de ti más se acercan a ser un equipo de Scrum auto organizado y ese, curiosamente, es uno de los objetivos del SM.

Bibliografía:

Bastante de lo expuesto aquí procede del trabajo de grandes agilistas, en concreto de “Coaching Agile teams” de Lyssa Adkins, “Scrum Mastery” de Geoff Watts y “Scrum, a Pocket Guide” de Gunther Verheyen.