¿Por qué se contrata a un Scrum Master?
He visto empresas que consideran la agilidad prácticamente solo como una ventaja comercial, y eso me da taaaanta lástima… Porque provoca que se tomen malas decisiones. Malas, malas, malas decisiones. Por ejemplo, contratar un par de scrum masters para que te cubran 8 equipos: «¡hala!, ¡ya podemos vender que somos ágiles!» y los scrum masters en cuestión se convierten en esto:
Seres robotizados que ya no dan pie con bola. Básicamente, creo que es la pura expresión de «quien mucho abarca poco aprieta». Te conviertes en un personaje que de vez en cuando aparece (acaba de salir de una reunión y ahora después se meterá en otra), hace su aportación como buenamente puede el rato que está, ayuda un poco en tareas de secretariado que nadie quiere hacer y que «para eso está el scrum master» -¿para qué si no?- y «¡hasta mañana en el daily meeting, chicos!». Es horrible. Es… scrum master de pandereta.
Dedicación profunda vs superficial
Teniendo que estar atenta a varios equipos…
¿Cómo haces para poder interiorizar los problemas, dificultades, impedimentos, necesidades que tiene cada equipo a la vez y así poder trabajar en ello a conciencia?
¿De qué manera dedicas tiempo de verdad a pensar en qué camino necesita tomar X equipo con su situación particular?
¿Cómo desarrollas un conjunto de objetivos, métricas, las mantienes al día (¡las automatizas o construyes alguna herramienta que lea de alguna API…!) e influyes con ellas?
Si no estás con el equipo de forma regular, ¿cuándo presencias momentos importantes que de repente emergen? Como cuando alguien comenta cómo se siente frente a algo, o cuando surgen preguntas de cómo podrían hacer esto o eso mejor, o cuando se decide en grupo «oye, a partir de ahora aquello ya no lo hacemos más» (las personas no solo hablan y reflexionan en las reuniones de retrospectiva, ¡por cierto!).
¿Cómo te enteras de un impedimento urgente si estás en otra reunión?
Y la que más me perturba: ¿Cómo llegas a ser un miembro más de un equipo si no formas formar parte de él realmente? ¿si solo estás de paso?
Mientras escribo estas líneas, siento que las respuestas son obvias: no se puede. No sirve de nada ser scrum master de varios equipos si tu nivel de profundidad en ellos pretende ser elevado. Hmm… aquí me surge la duda. ¿Qué pretenden las personas que deciden este puesto de trabajo?
Microgestión para poder entender
Mis jefes me han contratado para que consiga que los equipos aumenten velocidad, eficiencia y calidad (y con resultados pronto, a lo estilo Harry Potter. Uf, qué miedo). Lo que ocurre es que para poder llevar a cabo ese arduo cometido (susceptible de analizarse bien) se necesita foco, estar con el equipo y tener tiempo para pensar. Pues soy honesta si confieso que no he conseguido aún hacerme entender con mis superiores; que entiendan el dilema que yo veo tan claro cristalino.
Cada vez que hablamos de este tema acaban pidiéndome una lista de mis tareas, el tiempo que le dedico a cada equipo y mi agenda-calendario, porque a lo mejor «alguna reunión me puedo saltar, que seguramente voy a todas y no hace falta». Sinceramente, no tengo problema en compartir toda esta información y lo hago con gusto, pero el ejercicio deriva en cuestionar «si tiene sentido que yo asista a esto o lo otro», «si esta reunión podría ser de 30 min en lugar de 45» o «si realmente la tarea número 4 la hago cada 2 meses o cada 3». Es agotador…
Tener un Scrum Master en plantilla es ágil
¡Resumen! Tener un scrum master para varios equipos a la vez cuando lo que se necesita es otra cosa sirve para posturear.
Creo que los perfiles de management que yo he conocido no entienden bien el rol de un scrum master y las necesidades de los equipos de verdad (tampoco confían en explicaciones que podamos darles los scrum masters que ya tienen. A lo mejor la realidad es que no hay budget para más y si el gurú de la agilidad al que respetan de verdad les dijera lo mismo que nosotros, sí se lo replantearían). También siento que esas ganas de cambio y de transformación cultural no son puras en las medias y altas esferas, sino que se vive más como algo ajeno que va a suceder en los equipos si se coloca cada pieza en su lugar:
- Parece que hacemos Scrum (porque estamos lejos de hacer Scrum realmente)
- Adecuamos los roles como dicta la guía, los jefes ahora que se repartan entre scrum masters, product owners y stakeholders
- Les decimos a los desarrolladores que ahora tienen más autonomía, que pueden/deben auto-organizarse, y autogestionarse… solo para algunas cosas, jeje
- Además ponemos a varios scrum masters pululando reforzando estos mensajes y… ¡todo irá funcionando! 🙂
Pero en la sombra se sigue actuando como se viene haciendo desde hace años: sin confiar de verdad, sin dar espacio real para innovar o formarse, vigilando detalles, actuando como papás y mamás cuando hay conflictos, aceptando acumulación de proyectos de tiempo, coste y alcance fijos (el triángulo de hierro es que es de hierro) sin intentar otros modelos hacia los clientes, fiscalizando horas… y a la vez queriendo medir el ROI del cambio ágil.
¿Las transformaciones culturales dicen que pueden durar de 5 – 10 años? Me sabe mal decirlo, pero yo creo que en algún caso hará falta cambio de generación directamente. 😇