Fortalezcamos la confianza en los equipos

Desde hace un tiempo veo en los diferentes medios digitales que se hace mucha mención de que los scrum masters, product owners o agile coaches son personas que con certificado en mano creen que pueden ejecutar el rol, menospreciando el rol como tal. 

Me parece que hay mucho descontento respecto a quienes ocupan estos roles o similares, respecto a su experiencia, a las actividades que debe hacer, a su madurez y a su impacto en la organización. 

Personalmente creo que todos los roles son importantes en una organización y cada uno debe ser respetado, aun cuando la persona que lo ejecuta no tenga la experiencia que corresponda.Es más, quienes tenemos más experiencia somos los llamados a compartirla y asesorar constructivamente ya que tanto el inexperto como el experto forman parte de una misma organización y desde ese punto de vista, los logros de uno son los de todos.

Pienso que la agilidad nos ha brindado una ventaja muy importante dentro de las organizaciones: una forma de comunicación pareja que permite unir tecnología con el resto de áreas de una empresa.

Es importante entender que esa vieja práctica de hacer un par de tomos tipo enciclopedia británica que luego era enviada al área de tecnología más generaba enemistad que resultados. La historia nos lo dice.

A medida que las empresas van entendiendo la agilidad y cómo los involucra, vemos que personas de diferentes áreas del conocimiento entienden más sobre tecnología (sea lenguajes de programación o ambientes de infraestructura) y las personas de tecnología entienden más sobre negocio (que de por sí ya entendían desde el punto de vista de cómo funcionan los sistemas).

Sea como fuere, ahora veo un mayor entendimiento dado que se involucran temas como escucha activa o conversaciones constructivas cara a cara o fomentando la apertura a nuevos conocimientos u opiniones. Eso me gusta de la agilidad. Que habilita el que nos tratemos como pares.

Esto no es gratis. De por sí hay que transitar el camino que nos lleve a tener esa apertura y esas ganas de conocer lo desconocido, así como comunicar adecuadamente para que el entendimiento sea uniforme desde un punto de vista holístico.

Respecto a las organizaciones y asignación de roles de trabajo

Pienso que de por sí cada organización tiene un nivel de madurez propio y pide personal de acuerdo a lo que entiende como su necesidad, luego está el mercado mismo que permite a cualquier entusiasta con certificación en mano se postule a determinado puesto.

Creo que el que una persona con la experiencia inadecuada se proponga para un rol para el que no está preparado no tiene que ver con la agilidad y sus roles. A mi parecer es parte de cualquier rol o cargo que está siendo necesitado por cualquier empresa. Es natural en las personas el buscar mejoría y si se sienten indicadas para el puesto, y la empresa entiende que es a quien necesitan, de mutuo acuerdo generan un lazo laboral.

Lo mismo pasa si alguien dentro de una empresa busca una nueva opción laboral internamente, al inicio puede no estar tan bien preparado, pero si la empresa confía en él, pueden llegar a un acuerdo y hacer el cambio.

Ahora, que esto conlleva riesgo, siempre es así.

Si nombro a un asistente como gerente y no le doy el coaching adecuado, o mi estrategia de coaching es te tiro al agua, si no te ahogas, eras el que necesitaba, debo asumir el riesgo de sus errores dentro del ámbito que le corresponda.

Lo mismo si a un developer con poca experiencia lo insto a tratar en reuniones con el cliente sin el debido respaldo o apoyo.

Los diferentes líderes en las organizaciones deben considerar que al nombrar a alguien en un rol, deben caminar un tiempo juntos para que no sea tan drástica la transición de un rol anterior a uno nuevo; sobre todo si la responsabilidad cambia de manera radical.

He visto asistentes de contabilidad que los han nombrado responsables de contabilidad sin respaldo y llevar a una empresa prácticamente a quiebra.

He visto developers con poca experiencia entrar a reuniones con clientes y tomar control de la reunión con la madurez de alguien con más años.

No hay receta para esto, dependes mucho de la suerte.

¿Lo recomiendo? No. En definitiva, el confiar en la suerte para un rol clave es irresponsable; pero como lo mencioné arriba, depende de la madurez de la empresa; es situacional. Es decir, lo entiendo, pero no lo haría.

Respecto a los roles ágiles

Ahora, con respecto a los roles ágiles. Lo que más me preocupa de los diversos artículos o publicaciones respecto a la inutilidad de los scrum masters, product owners o agile coaches es que son roles claves y lo que se incentiva es a no creerles o no tomarlos en serio.

El solo enfocarse en que todos son malos en generalidad lo que puede generar es que no se genere la empatía necesaria para que un equipo dé su máximo. Es pensar que solo es necesario el rol de constructor de producto y que el resto es opcional.

Cada uno tiene un rol qué cumplir y es importante la colaboración de todos para que la agilidad fluya. A su ritmo. La empresa misma va a darse cuenta de sus propios errores y va a aprender de ellos.

Es más, creo que es dañino el juzgar a todos los roles por las acciones de algunos. Pero lo que me parece más dañino es que se predispone a las personas en que dichos roles no suman; generando la no participación o el vicio dentro de los eventos ágiles.

En conclusión

Tengamos eso en consideración. Pienso que sí está bien el hacer ver a quienes están interesados en ser seguir un camino de liderazgo ágil deben tener más que un certificado, deben tener experiencia tanto de éxitos como de fracasos y tanto de liderar en cascada como en ágil; todo suma. Que debe trabajar en su empatía, en su colaboración y cómo contagiarla, en que no todos los equipos saben de prácticas ágiles o les cuesta trabajar como equipo y debe habilitar que se encaminen hacia ello. En fin, dedicarse a ser un líder ágil o como deseen llamarlo, toma mucho esfuerzo y tiempo, como cualquier otro tipo de líder en otro campo del conocimiento.

Lo que creo que está mal es que se dé un mensaje que pueda dañar la apertura que los equipos constructores deben tener, una vez dañada esa apertura, no importa la experiencia del líder ágil, la tarea de recuperar esa confianza se multiplica. Entonces por poner un nombre “fancy” a un artículo o por poner un post controversial, afectamos la confianza de los equipos y eso es no que no debemos buscar.

No está mal dar feedback, pero recordemos, el feedback tiene un solo propósito: Que el destinatario mejore. (Pueden leer mi artículo al respecto: https://www.miblog.digital/2017/12/el-feedback-tiene-un-solo-fin.html)

No debemos afectar la confianza de los equipos, debemos fortalecerla.