Comunicación Agile para managers IT

¿Qué es mejor, que el manager IT redacte y envíe un documento de 20 páginas, o que transmita la misma información con un gráfico sencillo que se interpreta fácilmente de un rápido vistazo?

Como dice el manifiesto ágil, es mejor conseguir un resultado, que escribir documentación larga y extensa que nadie se leerá… así que, ¿qué queremos decir con “comunicación agile” para el manager IT?

Aquí no queremos ser unos fundamentalistas de agile, es decir, no digamos que “agile es bueno” porque está de moda o porque suena bien… es más fácil y más de puro sentido común: el enfoque ágil es una buena idea en general, y también lo es para la comunicación por parte del manager IT, veamos por qué.

Nuestra arma como managers IT: los radiadores de información

Lo primero que debemos decir es que, como managers IT, si tenemos un conjunto de personas a nuestro cargo queremos que sean un equipo, no simplemente un grupo de personas que trabajan juntas. Y un mínimo que tenemos que cubrir para eso es que la comunicación entre las personas del equipo y con nosotros sea sencilla, clara, siempre que haga falta, sin obstrucciones, sin que haga falta documentar todo lo que se dice…

Si en el mundo IT estamos madurando en la aplicación del enfoque ágil de trabajo en general, y de infinidad de metodologías ágiles en particular, ¿Cómo no vamos a promover este estilo ágil para la comunicación con nuestro equipo y con el resto de interlocutores?

El quid de la cuestión es que cada persona del equipo tiene derecho a decir lo que piensa, sin que esto se convierta en un brainstorming continuo ni en un constante nido de discusiones inacabables sobre cualquier cosa… y hacia los interlocutores externos, que lo que tengamos que decir lo transmitamos de forma breve, al grano y sin más adornos ni páginas de documentación de seguimiento de lo estrictamente necesario.

Un “radiador de información” es lo contrario que una “nevera de información”: un radiador es algo que cualquier persona del equipo puede ver y entender con total facilidad en el mismo momento. Los radiadores típicos estaban hechos con post its y presentados en la pared de la oficina… pero ya no es tanto así, puesto que el trabajo en remoto en el sector IT no deja de crecer, y por tanto seguimos actualizando la manera de construir y transmitir estos radiadores del equipo. Y decimos bien, “del equipo”, porque la información que contienen es transmitida por el equipo de trabajo: cuando hacemos un radiador, el manager (jefe de proyecto, jefe de servicio, responsable del contrato, líder facilitador…) debe limitarse a ser el “secretario” que anota ordenadamente lo que el equipo tiene que decir; éste es el valor más importante de los radiadores de información.

Y su segundo valor fundamental es la facilidad para ser entendidos: representan el paradigma contrario a los documentos “planos”, es decir, no hay que ir a rebuscar a determinada página para poder “leer” lo que se quiere saber… al contrario, un radiador “se mira y se comprende, se capta” de manera inmediata.

Vamos a proponer los más útiles que un manager IT puede utilizar en el día a día con ejemplos concretos y aplicables desde mañana mismo a primera hora de la mañana.

El radar

El radar es uno de los radiadores más potentes que un manager IT puede utilizar. Se trata de preguntar al equipo qué cuestiones o asuntos con los que les ocupan y preocupan en su día a día, y que sean libres de enumerar los que consideren; simplemente anotamos cada uno de éstos puntos, sin pararnos a comentar el detalle de cada uno de ellos, así que no es un brainstorming donde cada persona del equipo hace una disertación de cómo se lleva con el product owner o qué le parecen las herramientas de trabajo que estamos utilizando: esto sería inacabable, y un asunto que preocupa mucho a una persona puede que al resto no le interese demasiado.

La dinámica es más simple y rápida: anotamos los puntos de preocupación del equipo (por ejemplo el horario, la precisión de las estimaciones, su relación con el product owner, etc…), y después pedimos una votación para cada una: si estamos en persona, simplemente levantando la mano y “votando” de 0 a 5 con los dedos extendidos, o a través de cualquier herramienta de reuniones online con un chat (o utilizando la cámara para ver los votos); 0 significa “lo veo muy mal, no funciona, es un problema muy grave…”, hasta un 5 porque “es fantástico, la situación ideal. Si nuestro equipo es de 10 personas, el máximo posible son 50 puntos; representamos estas votaciones para cada asunto y después leemos el radar:

Está claro, y se entiende al instante, que este equipo siente que tiene problemas con la documentación y con la herramienta de pruebas, mientras que con el resto de asuntos se sienten, en general, bastante tranquilos.

Así que, si queremos cambiar algo, si vamos a esforzarnos en mejorar cosas, tenemos que hacerlo en la documentación y la herramienta de pruebas, no en hacer aún más perfecta cualquier otra cosa que ya tenemos bastante bien controlada.

Y todo esto no lo dice el manager (que puede participar en la votación o no), lo dice el equipo. Hemos hecho el radar en… ¿5 minutos, 10 minutos como mucho? A cambio de ese tiempo tan breve, conseguimos una información muy valiosa. Y si hay muchas dimensiones podemos agruparlas en radares diferentes: radar de pruebas, radar de herramientas, radar de interlocutores, etc…

Y aún podemos pensar en usos más interesantes que sólo para el propio equipo: si la única “dimensión” que sale mal valorada es la “comunicación con el product owner”, por ejemplo… podríamos enseñarle este radiador a ese interlocutor, para tratar de explicarle que el equipo está preocupado porque quizá no contesta a las preguntas, o suele hacerlo tarde, o de manera poco comprensible… y que todo ello puede afectar al avance del trabajo (lo cual nos perjudica a todos, incluido ese product owner).

O también, proponer siempre una dimensión que sea “Apoyo por parte del manager IT” para que se plasme si nosotros mismos estamos aportando la ayuda y apoyo que el equipo espera y necesita.

La mejor idea es refrescar esta información o rehacer este radiador cada cierto período de tiempo.

Por eso el siguiente radiador podría ser el plan de mejora accionable a corto plazo.

Plan de mejora accionable

Este elemento de comunicación sirve para responder a la pregunta de “¿En qué debemos aplicar el siguiente esfuerzo de mejora o de cambio respecto de nuestro día a día, para que los siguientes días de trabajo sean aún mejores que los anteriores, o al menos para que no sean tan malos como los anteriores?”

Una idea sencilla es hacer 4 cuadrantes del estilo “hacer más, hacer menos, empezar a hacer y dejar de hacer”.

En cada cuadrante registramos las propuestas que libremente se propongan, sin que nadie entre a rebatirlas o a discutirlas (porque sería inacabable). Aquí se puede proponer usar más el tablero kanban, hacer menos documentos, dejar de hacer reuniones de seguimiento, usar más una herramienta determinada… lo que sea. Todas las ideas son potencialmente buenas.

Y una vez anotadas, se “votan” como hemos hecho con el radar: cada persona se plantea si, por ejemplo, “empezar a usar un tablero kanban… es una idea genial” y lo vota con un 5; o bien que “enviar menos emails… no, ésa idea es muy mala porque necesitamos enviar muchos emails!” y lo vota con un 0 o un 1.
Sumando los votos para cada propuesta, en no más de 10 minutos hemos hecho este plan:

La mejor idea es señalar unas pocas propuestas ganadoras; no es que las demás no sean importantes, pero a corto plazo nos comprometemos a cumplir con esas 2/3 ideas ganadoras (estén donde estén, tanto si implican hacer algo más, como dejar de hacer algo…). Este radiador debería ser rehecho o al menos actualizado cada cierto período de tiempo.

Para este radiador podemos invitar a cualquier interesado o participante en el proyecto, no sólo a las personas del equipo: por ejemplo, ¿Y si hacemos esto con los usuarios finales de nuestro producto? ¿No estaríamos tomando muy buena información sobre qué quieren que haga dicho producto o servicio y hasta qué punto les parecen importantes unas propiedades u otras?

Reportes de seguimiento en un sólo vistazo

Decíamos que la comunicación fluida no sólo debe producirse de forma interna con el equipo, sino también hacia otros interesados externos.

Y sin duda para ganar esta batalla hay 2 radiadores que no por bien conocidos son poco importantes; justamente son conocidos porque no hay excusa para no generarlos a cambio de herramientas de comunicación más “tradicionales”.

Uno de ellos es el burndown: ¿para qué vamos a hacer un informe de seguimiento de 20 páginas explicando cómo va un proyecto, si se puede contar lo mismo en un sólo vistazo?

Si en cierta iteración, la línea real (en este ejemplo la línea azul) va por encima de la ideal… es que vamos retrasados, tanto más retrasados cuanta más distancia hay entre ambas líneas; y si prolongamos la línea real hasta el eje x, el punto de corte determina en qué iteración terminaremos, es decir, en qué fecha.

Aunque debajo de esta información breve hay mucho detalle (riesgos, retrasos problemas que van apareciendo, etc..), ¿acaso no es realmente el mejor resumen de cómo va el proyecto, y cuándo termina? Y, por lo tanto, el mejor “informe de seguimiento” posible que el manager IT puede presentar.

Por otro lado, la herramienta de comunicación más potente que puede utilizar un manager IT es el tablero kanban:

• Es la herramienta de comunicación interna del equipo más potente, puesto que señala quién está haciendo qué, qué peticiones (evolutivos o incidencias) estamos llevando a cabo, en qué estado de avance está cada una, si hay tareas que dependen de otras, si hay peticiones que dependen de otras, si hay atascos o dependencias con terceras partes que deben ser gestionadas cuanto antes, etc….

• Por todos estos datos que refleja, no sólo es una herramienta de comunicación interna sino “la herramienta maestra” para que el equipo se autogestione (no es el manager quien asigna las tareas en el tablero, sino el equipo quien se las asigna).

• Y, además, es una herramienta de comunicación con otros interesados puesto que leer el tablero kanban equivale a leer el estado de avance de la iteración de trabajo, por tanto también es el “informe de seguimiento” detallado.

Y muchos más: Los números y las palabras, la línea de tiempo…

En relación con la transparencia y la apertura en la comunicación, si el manager IT quiere saber cómo está su equipo, en lugar de interminables entrevistas individuales con cada persona, ¿por qué no pide a cada uno que escriba un número, por ejemplo, entre el -2 y el 2? -2 significa “no me gusta nada trabajar aquí”, y el 2 “estoy encantado de estar aquí”… ¿no es una forma rápida y sencilla de tomar la temperatura a un equipo y que el propio equipo sepa cómo está en general, más allá de excepciones puntuales?

Personalmente propongo utilizar tarjetas del mismo color y rotulador del mismo color para todas las personas del equipo… porque no estamos buscando “quién está mejor y quién peor”, sino cómo está el equipo, lo cual se transmite con total claridad como vemos en el ejemplo:

Y tenemos muchos otros ejemplos, como la línea de tiempo en la que marcamos los eventos positivos y negativos que acontecen, para hacérselos saber a interesados externos y que sepan que nos afectan; por ejemplo, marcando uno del tipo “El product owner no contesta a las dudas”, y ésto ha supuesto un parón en el avance del trabajo). Con ello facilitamos y reforzamos el mensaje que queremos transmitirle: “si usted como product owner se encuentra disponible cuando lo necesitamos, es más probable que consiga su producto cuando lo necesita, no simplemente queremos conseguir nuestro objetivo en cada iteración o cada resolución de una incidencia”.

Conclusión

En definitiva, para que las personas del equipo se puedan organizar y comunicar entre ellas, y para que los interesados externos conozcan el estado de evolución del trabajo… ¿no será mejor facilitar esta comunicación con radiadores y herramientas claras, que se entienden de un sólo vistazo, que se construyen en 10 minutos (o a veces menos), y que son más entretenidos de hacer que un simple, llano y aburrido documento que nadie leerá? Éste debería ser el principio general que guíe el estilo de comunicación del manager IT.