Hola Jerónimo.
Soy Alberto del curso de PSM del 13 y 14 de diciembre.
Estamos preparandonos los tests para hacer el examen y nos ha surgido una duda de un posible caso y como deberíamos actuar como scrum masters.
Nos encontramos en un proyecto con el equipo scrum formado al completo y dentro del developer team una figura se destaca por encima de los demas en los eventos, llevando la voz cantante, tomando decisiones y acercandose al rol de manager clásico del waterfall.
Entendemos que el developer team al ser autogestionado, nosotros no debemos interferir en principio.
¿Pero qué deberíamos hacer si vemos que la actitud de esa persona empieza a ser tóxica? Si el resto de miembros dejan de colaborar en los dailies y otros eventos. No aportan ideas y siempre se supeditan a las decisiones del primero. O incluso empezamos a notar actitudes tóxicas como malmeter, o dejar de lado personas y formar subgrupos.
Entiendo que este proceso sería una progresión pero no nos es ajeno y hemos vivido situaciones similares ya en el pasado que han llevado a equipos a situaciones tensas que impedian trabajar correctamente.
¿En que punto nosotros debemos (o quizas no deberiamos) actuar para poner coto a esta situación?
Un saludo y muchas gracias,
Alberto.
Alberto Castro
Esta cuestión es una de esas que aparentemente no tienen solución. ¿Cual es el contexto? ¿Qué está haciendo el equipo? Incluso podemos pensar que lo ideal es actuar directamente sobre el problema. Sin embargo, ¿Es esa nuestra labor como Scrum Masters?
El peso de la experiencia previa
En ocasiones, debido a nuestra experiencia como Scrum Masters, o previa a ser Scrum Master, nos encontramos con situaciones que sabemos como van a acabar, incluso antes de que empiecen. Si miramos lo que dice Scrum del rol de Scrum Master, encontramos que sus responsabilidades son dos: Mantener Scrum funcionando y eliminar impedimentos.
Cuando hablamos de impedimentos, siempre me refiero al trabajo del Scrum Master como proveedor de servicios a la organización, como se puede ver en la imagen de abajo. Estos son los impedimentos a los que se refiere Scrum. Arreglar teclados no es un impedimento. Interferir con las situaciones internas del equipo tampoco. Afortunadamente el rol Psicólogo del equipo Scrum no existe todavía.
A pesar de tener un equipo con miembros destacados que toman control del mismo, esto no necesariamente afecta a Scrum. Sin embargo, el Scrum Master puede ver esto como un impedimento a la agilidad. ¿Esto es así? Veámoslo desde un punto de vista sistémico.
Las diferentes posturas del Scrum Master
La imagen de arriba es del framework de competencias de agile coaches del Agile Coaching instutute. Podéis encontrar información sobre cada una de las áreas y recursos en su página.
Pensemos por un momento a qué tipo de intervención requiere este caso.
El Scrum Master actúa sobre el sistema (Organización y equipo Scrum) y no sobre individuales. En Scrum dejamos que el equipo de desarrollo se autoorganice y eso no siempre supone tener actitudes y resultados positivos. Positivos desde nuestro punto de vista. Si un miembro del equipo toma el control y el resto de miembros del equipo no hacen nada, entonces es autoorganización ¿No?
Los valores de Scrum
Sin embargo, hay cosas que si puede hacer el Scrum Master. La primera es hablar con miembros del equipo y explicarles que, si no toman acción ante algo, entonces nadie los va a hacer por ellos. Aludimos a un par de valores de Scrum: Coraje y Franqueza. Es labor del Scrum Master promover esos valores dentro del equipo.
En segundo lugar es establecer un espacio para que los miembros del equipo de desarrollo puedan hablar con franqueza. Al final depende de ellos tomar una decisión o no. Lo que está claro es que si la situación se sostiene en el tiempo, es muy posible que se produzcan distintas situaciones: Que uno de los miembros deje el equipo, que esta persona se canse, etc…
En la última actualización de la guía de Scrum se incluyeron los valores de Scrum, algo que Jeff y Ken definen como la savia que nutre Scrum, y sin los que Scrum no puede ser implementado.
Los alumnos como Alberto que pasan por alguno de mis cursos, saben que pongo mucho el foco en los mismos. En ocasiones, solamente hace falta pensar en ellos para dar con una solución, desde la perspectiva de Scrum al problema.
Esto no significa dejar otras soluciones de lado, como puede ser el coaching profesional o el mentoring, significa que el Scrum Master, como tal, debe dominar las herramientas de las que Scrum dispone para poder ofrecer un mejor servicio a su organización.
No es labor del Scrum Master intervenir directamente solucionando la situación, sino de aprovechar la situación para promover los valores de Scrum. En última instancia, si el equipo de desarrollo se siente cómodo con esta situación, es una manera de auto organizarse.
La frustración del Scrum Master
Algunos Scrum Masters se sienten frustrados porque ellos saben lo que hay que hacer. Sin embargo, como Scrum Masters, no es su responsabilidad tomar acciones, especialmente desde un rol tan delicado, que se puede ver como una figura de responsabilidad y al final generar un ambiente de confrontación que no va a favorecer su verdadero trabajo: que Scrum se entienda y se ponga en práctica en la organización.
Los mejores Scrum Masters son los que usan un pensamiento lateral para buscar soluciones a los problemas, no los que se atribuyen funciones orgánicas o el papel de psicólogos de equipo. Y al final, si el equipo decide no hacer nada ejerciendo la transparencia y la franqueza, entonces hemos dado con autoorganización. Y eso está bien.
Quizás no sea la solución que nosotros querríamos, pero es una solución que emerge desde la autoorganización, no desde la facipulación.
Muy de acuerdo con esta respuesta para un equipo Scrum dónde todos sus miembros pertenecen a la misma organización. Pero mi pregunta es, cómo lo hacemos funcionar cuando soy un proveedor, dónde el ScrumMaster es el rol que utiliza un JP de la empresa proveedores y participa en el proyecto de un developer teams que “tiene a cargo” a los ojos de su empresa.
Es una figura que siempre nos ha complicado a quienes somos consultores y abordamos el rol de ScrumMaster fusionado con el Jefe de Proyectos que es contraparte del cliente a quien le estamos ejecutando un proyecto.