¿Qué errores no cometer cómo Agile Coach?

Reading Time: 9 minutes

Tras todo un año trabajando como agile coach en una transformación de una gran compañía llego la hora de cambiar de aires y sobretodo de analizar lo ocurrido y hacer uso del principio número 12 del manifiesto Agile.

A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

https://agilemanifesto.org/iso/es/principles.html

Estos son algunos de los errores que creo que he podido cometer en algún momento y que he visto cometer a otros compañeros y que creo que pueden penalizar como Agile Coach cuando se convierten en un hábito. Estos errores ocurren muchas veces porque en lugar de transformar una organización nos vamos transformando y perdemos la perspectiva. Hay que entender que todos tenemos objetivos individuales y a veces debido a la presión o a los tiempos que nos exigen perdemos foco y cometemos errores.

El síndrome del eterno profesor

Muchas veces como Coaches nos convertimos en meros profesores. No hay que olvidad que la formación es una parte muy importante de un proceso de Coaching, pero no es el único. No todo lo que decimos debe ser una lección de vida, ni tenemos que esperar que una frase nuestra cambie la vida de la gente con la que trabajos. Nuestro trabajo debe generar un impacto real y no podemos pretender causar impacto sólo impartiendo formación y confiando en que la gente se crea lo que decimos.

No dedicar suficiente tiempo a entender el contexto

Muchas veces, como humanos que somos, emitimos juicios de valor. El problema es cuando los emitimos sin tener todo el contexto. Al principio puede que no pase nada, pero poco a poco va a ir generando un desgaste en las otras personas. Esta situación continuada puede derivarse en una resistencia que se escapa a nuestro control. Es un error que no debería cometer nunca un buen Agile Coach. Un buen Agile Coach tiene que observar antes de hablar. Muchas veces, por la forma de ser de algunas personas, estas actuan sin verdadero contexto y se dedican a promover acciones solo basándose en el síntoma. Esto les lleva a actuar sin realizar un diagnóstico profundo de la situación, lo que hace que se comporten como “elefantes en una cacharrería”.

Para intentar no caer en este error intento seguir tres pasos para entender el contexto:

  1. Observar lo que ocurre sin actuar. Aquello que ha ocurrido y queremos “corregir” puede ser solamente una casualidad.
  2. Observar si un hecho ha vuelto a ocurrir. En este caso empezaría a indagar si la gente es consciente de lo que ocurre y ver si nuestra hipótesis puede ser correcta.
  3. Observar y confirmar que nuestra hipótesis es correcta. En este último paso expondremos nuestra hipótesis y promoveremos una generación de acciones para corregir la situación

No preocuparse de la visión sistémica

Debido al trabajo del día a día muchas veces nos olvidamos de los impactos que queremos generar en la transformación. Es importante que tengamos siempre una visión sistémica. Esto es algo que aprendí en la formación de LeSS que recibí del propio Craig Larman. Gran parte de la formación la dedicamos a entender cómo elaborar una visión sistémica a base de mapas de variables. Una vez creado este mapa (gigantesco cuando hablas de corporaciones) es muy sencillo ver cómo un cambio en un aspecto, que parece inocente, desencadena una serie de problemas generales en el sistema.

Muchas veces nos olvidamos de esto. Por ejemplo, introducimos una pequeña métrica en nuestro sistema, por la necesidad de enseñar la evolución de un programa. Esta pequeña métrica puede desencadenar una serie de preocupaciones o sistemas de control que hacen que el rendimiento de un equipo se vea afectado. Ahora viene el siguiente problema, como no tenemos modelado nuestro sistema, no podemos justificar que ese cambio ha ocurrido por esa pequeña métrica. Esto nos genera una visión muy pobre de nuestro sistema.

No poder referenciar el manifiesto Agile

Una máxima que cualquier Agile Coach debe tener y por desgracia me he encontrado con muy pocos que puedan hacerlo. Hacer referencia literal al manifiesto Agile. Con verdadero conocimiento, no solo repetirlo de memoria. Hay que dedicar un gran esfuerzo a entender el porqué del manifiesto, de sus valores y principios. ¿Cómo se relacionan con el día a día? ¿En qué situación aplica el principio número 10? ¿Cuando al aplicar un framework nos estamos cargando el manifiesto?

Yo intento cada cierto tiempo repasar el manifiesto Agile, trato de sabérmelo de memoria, lo repito varias veces a la semana. Esto me ayuda a referenciarlo y hacer real la palabra mas importante de mi rol : AGILE. Pero además voy tomando notas de preguntas, situaciones o hechos para cada uno de los principios. Porque Agile no es SaFe, o experiencia laboral, o JIRA, o PPTs, Agile es el manifiesto y me parece que todo Agile Coach debe tenerlo interiorizado y poder referenciarlo con sus palabras exactas, porque cada palabra es importante.

Hablar mas que escuchar

Viene muy relacionado con el tema de la visión sistémica y el contexto. Una de las primeras cosas que debe tener y trabajar un Agile Coach es la escucha activa. Esto no lo digo yo, es una de las primeras cosas que dice Rachel Davies en su libro Agile Coaching, o el libro de Coaching de Leonardo Wolk. Muchas veces la gente necesita hablar para ir ganando confianza y poco a poco ayudarnos a profundizar en el problema. Es un error que cometo bastantes veces, hay que dejar a la gente que se exprese libremente.

En mi caso creo que cometo este error porque tengo miedo de olvidarme lo que quiero comentar. Otra cosa es lo que les ocurre a muchos Coaches, buscan el “momento de gloria” del Agile Coach. Intentan dar una lección magistral, o un argumento aplastante y muchas veces eliminan este espacio tan necesario para la gente con la que trabajamos. Un coach debe escuchar mucho, mucho más que hablar.

Humildad. No reconocer los éxitos de los demás

Creo que nadie que se dedique al Agile Coaching puede decir que algo ha ocurrido porque él ha hecho algo. O por lo menos yo no veo cómo se puede atribuir directamente a sus acciones. Muchas veces las cosas ocurren o van a ocurrir independientemente de lo que hagamos como Agile Coach. Nosotros lo que hacemos es acelerar que ciertas cosas ocurran. Nuestra área de conocimiento no es algo imposible de adquirir por otros. No trabajamos en los límites del conocimiento ni con tecnología puntera. Nuestra experiencia no es mejor que la experiencia de otros. Esto nos lleva a que la gente puede llegar a las mismas conclusiones que nosotros o incluso a otras mejores por otros medios.

Es muy importante que un Agile Coach sepa mantenerse humilde y potenciar el éxito de los otros. No debes atribuirte los éxitos de otro y menos decir o insinuar que ha sido porque tu has sido el Coach. Una cosa es poner en valor nuestro trabajo y otra pensar que somos infalibles o auténticos genios. Pero sobretodo hay que reconocer los méritos de los demás, sobretodo cuando nos han permitido participar o nos han contado sus ideas. No todo ocurre porque haya Coaches cerca. El mérito no es solo tuyo, de hecho casi seguro que no es tuyo ni al 20%.

No dedicarle suficiente tiempo a la preparación de reuniones o eventos e improvisar constantemente.

Ya lo he comentado en el blog en el artículo La preparación como clave del éxito. A la hora de una transformación es importante conocer cuales son los tiempos de ejecución, pero también los de preparación. Suele ser un error ligado a la falta de humildad: “Como soy muy bueno no necesito preparar nada, solo improviso”. Voy a poner un ejemplo:

Un Scrum Master tiene una retrospectiva. Un Agile Coach nunca le dirá lo siguiente:

Es fácil. Tu vas a la retro, sin nada preparado y vas improvisando.

Escuchado de algún Agile Coach

Al contrario, en esta situación, un buen Agile Coach le dirá que tiene que dedicar cierto tiempo a preparar la retrospectiva, plantearse los problemas que cree que hay, que dinámica va a seguir la retro, que espera conseguir. Lógicamente esto lleva un tiempo. A los Scrum Masters les digo que si la retro es de dos horas, se reserven por lo menos 4 para prepararla bien. Poco a poco la experiencia les dirá que ese tiempo quizás no es necesario dada la madurez del equipo, etc. Pero lo que está claro es que siempre tendrá que dedicar tiempo a prepararla.

Pues esto es algo que muchas veces como Agile Coach no somos capaces de aplicar. Imaginad que tenéis una formación de varios días, ¿cuánto tiempo dedicaríais a prepararla? Sería muy arrogante pensar que te puedes levantar una mañana cualquiera y ale, improvisar una inception. Tenemos una gran responsabilidad como Agile Coaches.  De forma que nuestras intervenciones deben ser un éxito siempre. Nuestras intervenciones buscan cambiar, no podemos dudar en lo que hacemos , debemos tener seguridad y esa seguridad la da en una gran medida la preparación.

No estar mas tiempo sentado con los equipos de desarrollo

Esto es algo que echo mucho de menos en los Agile Coach. Para entender el sistema, para observar el contexto, para escuchar las conversaciones, para ver las prácticas, etc; no basta con ir a las dailies y a los eventos o reuniones que nos convoquen. Hay que estar sentado con el equipo en el día a día. Hay que comer con ellos, hay que trabajar con ellos, hay que hacer software con ellos.  No solo tenemos que trabajar con la alta dirección, o con los Scrum Master y Product Owner. Relacionado con la humildad hay que entender que no somos mejores que los desarrolladores.

No dejar espacio para que los equipos se equivoquen

Otro de los errores que creo que muchas veces cometemos es intentar que las cosas vayan muy deprisas. Un proceso de coaching es un proceso de aprendizaje, y no hay aprendizaje sin error. Si alguien no hace mas que hablar de lo bien que lo ha hecho siempre, desconfía de el. Todos nos equivocamos y en un proceso de transformación o de coaching la gente debe equivocarse. Evidentemente no queremos que una empresa se hunda porque no hacemos algo. Pero hay que saber mirar al futuro y no querer ir demasiado deprisa. La inacción como acción del cambio.

Decir mas veces la palabra yo, que cualquier otra

Otra vez tengo que insistir que el Agile Coach es la persona mas prescindible en un proyecto. Somos agentes de cambio, no el cambio en sí mismo. Hacernos imprescindibles es un gran error. Debemos ser garantes de que las cosas ocurran. Por eso mismo no debemos tener la palabra yo por delante. Son frases que todos tenemos en nuestro vocabulario común:

  • Yo lo que hago….
  • Yo lo que hacía …
  • A mi me funcionaba …
  • Debes hacer…

Es importante no caer en esto y usar otros términos. Imaginaos esta conversación:

  • [SM] Las dailies se alargan mas de 15 minutos.
  • [Coach] Yo lo que hago para eso es poner un temporizador para que no se pasen.

Fin de la conversación. ¿Os parece útil? ¿Cual es el margen de mejora que tiene el Scrum Master? ¿Por qué va a usar nuestra solución?

Ahora imaginad esta otra conversación:

  • [SM] Las dailies se alargan mas de 15 minutos.
  • [Coach] ¿Pero se alargan normalmente?
  • [SM] Si, es una constante, antes lo hacíamos bien, pero algo ha cambiado.
  • [C] ¿Hay alguna diferencia en la daily?
  • [SM] se ha incorporado un chico nuevo que copa todas las conversaciones
  • [C] ¿Qué opciones tienes para trabajarlo con el chico nuevo? ¿Ha trabajado alguna vez con Scrum?
  • [SM] Creo que no
  • [C] ¿Se te ocurre alguna forma de que estar persona conozca como se trabaja con Scrum? ….

Como veis el lenguaje es completamente diferente. Si además en lugar de usar un lenguaje categórico y cerrado usas preguntas abiertas, la experiencia es mucho mas gratificante. Además damos lugar a que otros se equivoquen y aprendan. Y sobre todo tenemos que tener claro que es imposible que seamos poseedores de toda la verdad. Nos equivocamos nos guste o no y hay que saber reconocer los errores. Con la segunda conversación es posible que el cambio sea mas lento, sin embargo va a ser mas duradero que con la primera. Existe una posición de propiedad por parte del Scrum Master sobre las acciones a llevar a cabo. En la primera el Coach es el que “manda”.

Nunca decir que no

El cliente para el que trabajé en el último año me dijo un día, habéis venido a transformarnos y os estamos transformando nosotros. Esto fue algo que me llegó muy al fondo, así que decidí que para transformar no puedo hacer lo que me dicen que haga. Esto me llevó a ver que las personas de mi alrededor tenían una actitud condescendiente y de siempre ceder a todo lo que les pedían. Enmascaraban esto diciendo que había que ser político, que había que saber tenerles contentos por el negocio, etc. La realidad es que buscaban contentar en lugar de transformar, así quizás conseguirían acabar formando parte de aquellos que iban a transformar.

Hay muchas cosas en el trabajo de un Agile Coach que implican decir que no. Esto es algo que debemos aprender y saber que corremos un riesgo. No puede ser que hablemos de motivar a la gente permitiendoles dedicar tiempo a sus vidas, conciliar, etc y luego llegar a la primera de cambio y cambiar nuestros planes personales porque al responsable de turno se le ha antojado convocar una reunión “urgente” a las 19:00 de la tarde. Esto es solo un ejemplo, pero hay muchos que enumerar y que he visto que ocurren: Cambiar nombres a eventos y artefactos porque si, no convocar reuniones, saltarse retros, hacer ppts a discreción, etc. Y en ningún caso se dice que no.

Faltar al respeto.

Parece mentira que tenga que cerrar el artículo con este error. Parece mentira que haya que decir esto, pero he visto cometer este error bastantes veces (espero no haberlo cometido nunca). Si, aunque parezca de locos, hay Agile Coaches que faltan al respeto a otros coaches, a la profesionalidad de la gente, a los equipos, etc. De hecho he sufrido ofensas y faltas de respeto de algunos que se hacen llamar Agile Coaches. Y no hablo de una opinión, sino de ofensas reiteradas. Sin embargo esto no ha hecho mas que afianzar  en mí el hecho de no ser como este gente. En casos como los que menciono solo puedo decir que “aunque el mono se vista de seda, Jefe de proyecto se queda”.

Espero que estos errores que cometen muchos Agile Coaches, algunos también los cometo yo, sirva para entender un poco mas esta figura y sobre todo para la autoreflexión de muchos. Para mí, reconocer mis errores es el primer paso para la mejora continua.