En empresas donde se está introduciendo Scrum, es habitual contratar los servicios de un Agile Coach, que realiza las funciones de Scrum Master de forma temporal. Esto lleva a situaciones extrañas, pues el coach es un empleado externo y no tiene los recursos necesarios para facilitar la labor del equipo. Por ello, yo siempre voto por tener Scrum Masters de plantilla, de forma que puedan acceder mejor a los recursos de la empresa y facilitar con eficacia el trabajo del equipo. Por ejemplo, si el equipo necesita un panel de cartón pluma, rotuladores para pizarra y pósits, un empleado los puede conseguir a través del departamento de papelería de la empresa, mientras que un externo no puede acceder a dicho departamento.
Esto me recuerda a una empresa donde se formó un equipo Scrum y, como no tenían Scrum Masters en plantilla, tuvieron que contratar a un Agile Coach que hiciese las funciones de Scrum Master. Llamaremos al coach Mad.
Durante unos meses Mad ejerció las funciones de Scrum Master, ayudando a Caroline, la Product Owner del equipo, a formar un roadmap y a alimentar el backlog con historias de usuario que cupiesen en Sprints de dos semanas.
En la foto final que tenía la empresa, los Scrum Masters acabarían siendo todos de plantilla, por lo que se empezó a buscar entre los empleados a profesionales que tuviesen los conocimientos para ejercer este rol. Así es como dieron con Robert, un experimentado agilista, el cual se trasladó de departamento, pasando a ser oficialmente el Scrum Master del equipo de Caroline.
La empresa, en vez de trasladar a Mad a otro puesto, o dejarlo para crear un pool de coaches, mantuvo a Mad como coach del equipo, a la par que Robert. Robert, que ya traía su bagaje agilista, pronto se dio cuenta de que el equipo tenía carencias en sus conocimientos de Agilismo.
En mi tercer libro, «Agile Coaching para Scrum Masters», explico las cualidades que ha de tener un coach, y lo describo como alguien con mucha templanza y humildad, que sabe escuchar, lanzar preguntas poderosas y motivar al equipo a alcanzar objetivos y a seguir un camino de Mejora Continua. Vamos, que describo a los coaches como supermujeres y superhombres.
Pero Mad distaba mucho de esta idea tan excelsa que tengo de los coaches, y pronto empezó a entrar en conflicto con Robert, puesto que Mad tenía su forma personal de entender el Agilismo, y no aceptaba usos y costumbres distintos a los suyos, como los que traía Robert. Mad se negaba sistemáticamente a cualquier propuesta que hiciese Robert, argumentando siempre que «el equipo no estaba preparado». Desde el punto de vista de Robert, precisamente el equipo no estaba preparado porque Mad había dedicado la mayor parte de su tiempo a Caroline, para preparar un roadmap con hitos bien definidos. Esa labor era crucial y aclaró mucho la visión que Caroline tenía del producto, pero ahora era momento de que el equipo empezase a sacar trabajo adelante.
Robert, al darse cuenta de que Mad era realmente un «stopper», tuvo que hablar en privado con él, utilizando comunicación no violenta (explicada en mi tercer libro: «Agile Coaching para Scrum Masters»):
—Mad, cuando planteo un cursillo de formación a los chavales y veo tu negativa a darlo, me siento obstaculizado, porque necesito que el equipo tenga la teoría clara para entender por qué Scrum prescribe esas reuniones y esa forma de trabajar. Por ello, te pido que, puesto que soy yo el Scrum Master del equipo, me dejes darles libremente el curso, sin obstaculizarlo. Valoro muy positivamente la labor que has realizado con Caroline, diseñando el roadmap de la aplicación, pero ahora he de poner el foco en el equipo, para que empiece a sacar tareas del backlog y se ponga con ellas en el siguiente Sprint.
—Rob, te noto frenético. Tú tranquilo. Ya le di yo la formación al equipo, así que ahora no es necesario quitarles más tiempo.—Le contestó Mad.
—¿Qué les has contado, exactamente?
—Pues los roles y las ceremonias que tiene Scrum. —contestó Mad.
—Mira, me he leído el libro «Scrum para No Informáticos», el cual te recomiendo, y en él se explican las claves para llegar a convertirse en un agilista de verdad, porque no es lo mismo «ser agilista» que «practicar agilismo». Los chavales no saben estimar con puntos de historia, no saben cuál es su velocidad, no saben cuál es la clave del compromiso y no saben por qué tienen que acudir todos a las reuniones. Mi compromiso con el equipo es convertirlo en un «equipo de alto rendimiento» y acabar con éxito este proyecto.
—¡Puntos de historia! Eso es muy complicado. Les he dicho que un punto de historia es una hora de trabajo sin interrupciones, para que lo tengan como referencia en sus estimaciones. No es el momento para que estimen con puntos de historia abstractos. —comentó Mad.
—Nunca me he encontrado con un equipo que no pueda estimar en base a puntos de historia, abstrayéndose de la variable tiempo, y creo que este equipo también podrá hacerlo. De todas formas, ellos son los que tienen que tomar la decisión, por lo tanto les preguntaré en la reunión de retrospectiva si les gustaría ampliar conocimientos. —contestó Robert.
Días después, Caroline se quejó a Robert de que éste pretendía dar un curso al equipo, cuando Mad ya les había dado un curso. Era obvio que esa información se la había dado Mad, pero como Robert era prudente, prefirió no inferir y le preguntó directamente a Caroline cuál era la fuente de esa información, a lo que la Product Owner respondió que había sido el coach Mad.
Se pueden imaginar el ambiente enrarecido que creaba Mad, frenando constantemente las ideas de Robert, y encima quejándose a Caroline por la espalda. Y lo más vergonzoso de todo es que Mad era supuestamente un Coach certificado.
Por lo tanto, si quiere distinguir entre un Agile Coach verdaderamente profesional y otro que de Agile Coach sólo tiene el nombre, le recomiendo la lectura de “Agile Coaching para Scrum Masters».
De esta situación aprendí que los equipos han de ser entes estables, donde Scrum Master, Product Owner y Desarrolladores han de estar juntos desde el principio. Los cambios en el personal hacen daño, y más aún cuando son cambios donde se duplica la persona que asume el rol de líder.
Mad, tras la venida de Robert, debería haber dejado el equipo, pues su misión ya estaba cumplida y su presencia no hacía más que meter ruido y enrarecer el ambiente. Cuando me he encontrado con esta situación en otras ocasiones, pero esta vez con Coaches de verdad, he observado cómo estos aprendían cosas nuevas del Scrum Master, pues nunca se deja de aprender, y puede ser muy enriquecedor observar cómo aplican otros el Agilismo. Todo esto aparte de dejar al Scrum Master ejercer su rol, sin poner obstáculos.
Pero, por definición, sostengo que hay que evitar la duplicidad de líderes en un equipo y, si no queremos prescindir de los Coach, aconsejo crear un «pool de Coaches», de forma que puedan ayudar, resolviendo las dudas que les surjan a los Scrum Masters en el día a día.
Fenomenal, Antonio, como siempre!!! Muchas veces me he encontrado con puestos aparentemente duplicados, no en temas de Scrum, pero sí en temas de gestión, donde una de las personas hacía todo el trabajo y la otra, simplemente, exponía ante superiores el trabajo que hacía la otra. Es bueno saber cuándo tu trabajo ha terminado y debes pasar a realizar otros proyectos o tareas.