Uno de los dolores más frecuentes de un Agile Coach es asegurarse de que el equipo va en la dirección correcta. A veces nos enfrentamos a diferentes tipos de madurez, cada uno va hacia un objetivo diferente, son orígenes diversos y experiencias diversas que a veces destacan, pero que tenemos que alinear hacia el mismo objetivo. Aunque algunos roles como Scrum Master y Product Owner tienen funciones bien definidas y rituales bien conocidos, el Agile Coach a veces se pierde en el mundo de posibilidades y formas de guiar al equipo.
Durante el tiempo que viví y trabajé en los Países Bajos tuve dos mentores que me marcaron: Hans y Pascal, el primero fue un mentor educativo, pero me dio un caso práctico y un trabajo que resolver. El segundo fue un mentor profesional, que me dio un caso teórico, cuya resolución requería mucho estudio. Lo que ambos tenían en común era que ninguno de ellos me decía cómo debía resolver el problema, ni qué debía hacer para resolverlo. Al contrario, se limitaron a decirme por qué habían elegido ese reto y cómo me ayudaría a desarrollarme.
Hans es un hombre muy peculiar, tiene unos 50 años, vive a 17 km de su trabajo y va a trabajar todos los días en bicicleta. Es jefe de departamento y almuerza con los alumnos. Durante todo el tiempo que pasé con él estoy seguro de que hablé mucho más de lo que escuché. Sus preguntas eran precisas y su comunicación extremadamente activa. El problema que me planteó era algo nuevo hasta entonces: cómo diseñar una red de abastecimiento de agua para una ciudad cada vez más pequeña.
Yo no sabía nada de hidráulica, mientras que él era un maestro en la materia, yo no sabía nada de suministro de agua, y él tenía años de experiencia. Durante nuestra primera conversación me dijo "me muero por aprender de ti cómo resolver este problema" y yo le contesté que no tenía ni idea de por dónde empezar, y él sonrió diciendo "yo tampoco, ¿no es emocionante?".
Hans probablemente dedicó entre 8 y 12 horas a enseñarme algunos conceptos básicos, pero desglosados en pequeños fragmentos. Nunca me contaba toda la historia, siempre me dejaba con un interrogante detrás de la oreja, siempre sabía que la próxima vez traería algo nuevo, algo extra. Lo más divertido era que sabía en qué fase me encontraba y en cada reunión me mostraba un nuevo paso que podía dar en busca de mi solución.
Lo mismo ocurrió con Pascal, mucho más joven que Hans y, por qué no, mucho más loco. Pascal siempre acudía a las reuniones muy despeinado y con la cabeza llena de ideas; quizá por eso tenía tantos problemas con los peinados. En el caso de Pascal, el reto consistía en implantar la gestión de servicios para una familia de 5 miembros: lo más improbable es aplicar los flujos de procesos y las mejores prácticas de ITIL. Incluso va, pero es como un cañón matando una mosca.
De nuevo no sabía por dónde empezar, y aunque Pascal ya estaba acostumbrado a aplicar este mismo ejercicio con varios consultores, se empeñó en explicarme que no había una respuesta correcta, sino que le interesaba más ver "hasta qué punto podía pensar fuera de la caja". Fue un ejercicio para elaborar analogías, y empezamos a programar reuniones periódicas con el único propósito de mejorar mi desarrollo y mis conocimientos sobre el problema.
Encontrar un nombre para las reuniones periódicas puede ser todo un reto, pero un día me llamó para tomar un café y me preguntó qué me rondaba por la cabeza. Dije que me sentía como si estuviera volando, viendo muchas posibilidades diferentes, y que cada vez que teníamos nuestras conversaciones volvía a poner los pies en el suelo, reconectaba con mi propósito y emprendía de nuevo otro viaje hacia el problema. De ahí surgió el nombre de nuestras reuniones: Touch Base
Cuando empecé a trabajar como Agile Coach, traje conmigo la misma rutina, un momento para conectar con el equipo. Al trabajar con varios agilistas quedó claro que cada uno estaba en un camino extremadamente nuevo, y que había varias posibilidades y formas de explorar el problema. A diferencia de las típicas conversaciones entre jefe y empleado, en las que la atención se centra en ver el estado de los entregables, touch base es una conversación entre colegas, en la que el agilista vuelve a la base para reponer fuerzas, es un momento para reconectar y preocuparse personalmente.
Hans y Pascal, no eran profesionales ágiles, pero procedían de una cultura extremadamente horizontal (la cultura holandesa), que es tan horizontal que ni siquiera tiene monumentos para venerar a sus héroes, y la diferencia salarial entre un C.E.O y un becario es relativamente baja.
A pesar de no ser profesionales ágiles, eran coaches que tomo como referencia de por vida. Con ellos me di cuenta de que un Agile Coach tiene que ser capaz de practicar la empatía con el equipo, desaprender lo que sabe, ponerse al lado de los Agilistas y entender por qué dificultades están pasando.
Hans y Pascal tenían una cultura totalmente diferente a la mía, y actuaron en mi propia transformación cultural, con ellos aprendí que es importante mantener la ansiedad y dar el tiempo adecuado para que cada persona del equipo pueda aprender de hecho los cambios que estamos proponiendo, más que eso, es importante que se sientan parte de la solución, y que esta solución viene de ellos, así estarán aún más dispuestos a mantener vivo el cambio.
También aprendí que tenemos que dar al equipo las herramientas adecuadas para explorar, a veces estas herramientas vienen con preguntas, a veces vienen de una intuición. La verdad es que más importante que una fórmula mágica es la necesidad de observar activamente si el equipo es capaz de salir en "viajes exploratorios" y arriesgarse a innovar y aportar algo nuevo. Por eso es importante que el Agile Coach aporte una nueva perspectiva al equipo, un nuevo punto de vista, y que el equipo pueda explorar esa perspectiva.
A veces volver a la base es repostar la energía que el equipo necesita para atravesar un momento complicado, a veces es adquirir conocimientos para afrontar un reto complejo, a veces es simplemente compañía y un lugar donde desahogarse.
Con el tiempo empecé a seguir un consejo de Kim Scott en su libro Assertive Empathy, cuando trabajo con un equipo de hasta 5 personas intento reservar hasta 50 minutos a la semana para hablar con el equipo. Cuando el equipo llega a 10 personas, ese tiempo se reduce a 25 minutos. Cuando se trabaja con más de 10 personas (que no es lo ideal), esa cifra se reduce a 25 minutos cada quince días. Para algunos puede parecer mucho, pero si nos paramos a pensar que la función de un líder es servir a su equipo, nos damos cuenta de que no basta con saber lo que le pasa al equipo.
En la práctica he notado que con los Agilistas 25 minutos cada quince días ha sido suficiente, primero porque suele coincidir con el periodo de sprints (para sprints de 2 semanas) o la mitad de ellos, para sprints de 4 semanas. Dar el tiempo necesario para que las actividades se desarrollen según las necesidades.
En resumen, Touch Base se ha convertido en mi scrum de la "quinta ceremonia", con un Time-Box de 50 minutos, que puede tener lugar semanal o quincenalmente. Donde trato de entender 3 cosas:
1- Cómo se siente el equipo;
2- Qué herramientas están utilizando y cuáles pueden utilizar;
3- Cómo puedo facilitarles la vida;
Además, las sugerencias salen homeopáticamente, lo que provoca cierta ansiedad a las personas más analíticas y directas, como yo, pero al mismo tiempo ofrece resultados duraderos a largo plazo.
Incorporar esta ceremonia a su rutina diaria favorece enormemente la maduración del equipo, lo que aporta resultados duraderos a largo plazo. Es la clave para lograr un desarrollo sostenible de nuestros equipos y conectar personalmente con el equipo. Por eso recomiendo una base de contacto para tu próximo sprint.
Kommentare