Hace unas semanas empecé a trabajar con una nueva Scrum Master en uno de mis clientes y ahora tiene una gran frustración. Durante los últimos meses en esta organización, hemos trabajado mucho en la auto-organización y en ser capaces de entregar un incremento terminado al final de cada Sprint.
En este cliente, los equipos de desarrollo son independientes y suficientes. Trabajan con el Product Owner en elaborar el Product Backlog y tienen poder para decidir a quien contratar y despedir, como realizar su trabajo -el CTO está especialmente orgulloso de Scrum y de las mejoras que ha traído- así cómo mejorar el producto. Ellos son responsables de la calidad, y también de su frustración.
A pesar de ser yo el primer filtro para Scrum Masters, no decido quien se incorpora. Son los propios equipos quienes lo hacen. Ellos son los que entrevistan y contratan a sus propios Scrum Masters. En este caso, Marta -nombre ficticio- demuestra ser una persona proactiva que entiende como funciona Scrum. Después de un año como Scrum Master en una organización y unos meses como Agile Coach en otra, se ve como una experta en Scrum. Y a pesar de ello, tiene una gran frustración.
Marta quiere hacer cosas, en lugar de centrarse en crear un espacio donde otros hagan
Al llegar a la oficina por primera vez, Marta se ha visto con ganas de hacer muchas cosas. Cree que hay que definir mejor el trabajo del Product Owner y el Product Backlog. También ve que el equipo no llega con el testing y ella misma se pone a testear. Lo mismo con las tareas no planificadas: ha propuesto crear un tablero donde visualizar todo el trabajo no planificado que tiene que hacer el equipo, el que no está previsto dentro del Sprint. En el caso de los Scrum Masters, cree que deberían hacer planes conjuntos sobre como cambiar la organización. Establecer metas comunes y luego implementarlas. Crear equipos de alto rendimiento.
Sin embargo, el resto del equipo no piensa que esas sean sus tareas. Ella no está de acuerdo. Quiere sentarse y preparar un plan de mejora, trabajar en que el equipo sea más feliz y se comuniquen mejor. Sin embargo, el equipo piensa que ya se comunican adecuadamente y no hacen falta mejoras. A veces, ellos mismos se sienten mal al no entrar en lo que Marta quiere hacer. Ella ve que hay miembros del equipo que no hablan lo suficiente o que no comunican como se sienten.
A nivel organizacional, quiere cambiar la manera en que las cosas funcionan, cree que hay espacio para hacer los procesos más eficientes. Eso pasa por decirle a la gente como tiene que hacer su trabajo. Además, durante las retrospectivas, se siente frustrada de que el equipo no encaje bien con las actividades que quiere realizar. Su relación con el Product Owner no es la mejor; él piensa que quizás está intentando abarcar demasiado.
Hace unos días, le pregunté: Desde que empezaste ¿Qué has aprendido que te haya hecho mejorar como profesional? ¿Hay algo nuevo que hayas aprendido de como funciona Scrum? Su respuesta fue que esas eran preguntas muy difíciles. Efectivamente ha aprendido cosas. Como funciona la empresa. Recursos humanos. Desarrollo de producto. Y yo me pregunto de nuevo ¿Es eso lo que debería haber aprendido? ¿Está haciendo su labor como Scrum Master correctamente?
Marta no entiende qué es ser una Scrum Master
Mi opinión personal es que no. Efectivamente, Marta conoce Scrum, pero como Scrum Master está todavía en una etapa de desarrollo personal y profesional muy temprana. Marta quiere hacer cosas, en lugar de crear un entorno donde todo el mundo puede hacer cosas. Se ve a si misma como un experto que sabe qué hay que hacer, en lugar de como un soporte que permita que otros se desarrollen al máximo. Y esto es un problema, porque cuando es enfrentada a este respecto, ella cree que ese es el trabajo. Si el equipo tiene impedimentos, resolverlos; Si la organización es ineficiente, decirle como puede ser más eficiente.
Esta situación es muy común y es el estado de evolución que sigue al Scrum Master «Ordeno y mando». Existe un siguiente nivel en el cual los Scrum Masters entienden que su trabajo no es cambiar la organización, sino que tienen que eliminar los impedimentos que impiden que la organización sea cambiada… por otros.
«El poder de la Influencia indirecta» podría ser el título de tu próximo post que fuera continuación de éste donde trataras los diferentes beneficios de tener un rol como el de un Scrum Master dentro de un equipo/organización.
Creo que es efectivamente un punto bastante temprano en la carrera de Marta pero difícilmente evitable en la carrera de un Scrum Master. Todos tenemos un momento cuando estamos dando el salto hacia la ejecución íntegra del rol en el que nos sentimos «inútiles», tienes en tu mente, como Marta, un montón de ideas sobre cómo se podrían hacer las cosas pero careces de las habilidades para influenciar tu entorno y ponerlas en valor sobre las que construir un entorno seguro donde el equipo pueda experimentar bajo el marco de Scrum.
Esto sólo se consigue andando el camino con un equipo en una mano y un saco de libros en la otra…
Cuando estás más cerca del «coding», por ejemplo, es más fácil medir de forma objetiva tu aportación al equipo o producto, pero cuando ejerces tu rol como Scrum Master tu influencia es más difícil de medir ya que en muchos casos puede ser subjetiva o impactar en ámbitos o indicadores que a priori ni te planteabas como objetivos.
Esto nos crea inseguridad pero sólo andando el camino trabajaremos dichas habilidades así como la capacidad para interpretar o medir nuestro poder para influenciar en los equipos y en la organización (si es que fuera necesario…)
Gracias por el post!