Te cambio esa reunión por un mail: La comunicación en equipos ágiles

Hablar de metodologías ágiles no es referirse a algo nuevo en el mundo del software; estas surgieron hace varias décadas como un intento de actualizar y optimizar los modelos de trabajo en equipos interdisciplinarios y si bien en este pequeño articulo me referiré a su implementación en equipos de desarrollo de software sus alcances y posibilidades van mucho más allá de esta industria.

Somos ágiles… ¿Verdad?

En la actualidad es común (por no decir, la regla) que los equipos de desarrollo utilicen algún tipo o variante de una metodología ágil. Esto es fácil evidenciarlo en anuncios de trabajo donde es normal ver como puntos exigidos para los candidatos algún conocimiento en (por ejemplo) Scrum o Kanban y las preguntas sobre estas en entrevistas de trabajo tienden a limitarse al conocimiento de sus “ceremonias”…

–          ¿Haz trabajado con alguna metodología ágil? ¿Conoces cómo funciona?

–          Eeh si, dailys, plannings, retros, etc…

–          ¡¡Excelente!!

Y es que, pese al burdo ejemplo que acá te presente, este pequeño dialogo ficticio realmente no es tan ficticio.

Según, Agile Alliance en su encuesta “Agile Survey Results 2020” un 45% de los participantes creían que las prácticas ágiles eran meramente la implementación de rituales y eventos, en lugar de un enfoque en la mejora continua y la colaboración. Resultados similares pueden encontrarse en otras investigaciones cuando se consulta abiertamente sobre la percepción de la agilidad (real, vista en su día a día) a los miembros de los equipos.

¿Las organizaciones han minimizado los valores de la agilidad solo a un conjunto de ceremonias?

La respuesta puede ser variada y dependerá de la cultura organizacional, la implementación de scrum, por ejemplo, no trata sobre agendar dailys y otras ceremonias como si fuesen un mandamiento divino al cual todos los feligreses ágiles del equipo deben asistir por miedo a las penas del infierno, su objetivo general es profundo e implica comprender lo que se desea crear con este cambio, el cambio comunicacional, la confianza y el trabajo colaborativo de sus participantes, las “ceremonias” bajo este prisma, son solo un accesorio.

¿Y si hacemos una reunión?

Siguiendo en la idea anterior. Es conocido el meme de “esta reunión pudo ser un mail”. O lo que es para muchos lo primero que se les viene a la mente cuando piensan en agilidad “Reuniones, muchas reuniones”.

Existe, podemos asegurarlo, una idea errada sobre las reuniones en agilidad, el impacto de estas y su eficacia. Quienes hemos trabajado en equipos ágiles en proyectos complejos sabemos lo frustrante que se siente cortar el hilo de tu trabajo (desarrollo, creación de pruebas, etc) por asistir obligatoriamente a una reunión donde no se es un aporte, donde lo que se comenta tampoco lo es y donde sus interlocutores se extienden en ideas circulares o se sumergen en la poca claridad del mensaje… reuniones a las que se nos invita solo por ser parte del equipo o porque “debemos estar”. Y que no se mal entienda, muchas reuniones si son útiles para comprender el negocio, el producto, los objetivos, etc. Pero hay muchas otras que perfectamente podrían ser un mail… aunque aquí nos encontramos con otro problema, más profundo, cultural; ¿Quiénes leen todos sus mails? ¿tenemos la comprensión lectora adecuada?

Según la encuesta “Agile Work Survey” de Atlassian (2023) el 70% de los miembros de equipos ágiles afirmaron que las reuniones son esenciales para la colaboración, pero a su vez se sienten abrumados por la cantidad de reuniones y sugirieron que muchas podrían ser más breves o bien estructuradas.

En consecuencia, la encuesta “Agile Trends Report” de Agile Alliance (2023) reporta un dato similar indicando

“Aunque las reuniones diarias y las retrospectivas son valoradas, el 50% de los encuestados mencionó que a veces se sienten ineficaces y que hay un deseo de encontrar formas más eficientes de llevarlas a cabo.”

Los principales problemas suelen identificarse como la falta de objetivos claros en las reuniones planificadas, el timing de estas, y tal vez el punto mas relevante a trabajar; la capacidad comunicacional de los interlocutores.

¿has estado en dailys que duran más de una hora?

Demasiada información o muy poca información.

Discernir sobre lo que se debe informar al equipo es y será siempre un tema en constante evolución en los equipos ágiles, por un lado, incluir al equipo en muchas reuniones tiende a generar conflictos a la hora de diferenciar sobre lo que es información realmente útil y lo que es accesorio o materias de otras áreas, por el contrario, limitar la información estrictamente a los directamente interesados puede ser dañino para el desarrollo y la calidad del producto. Supongamos un par de ejemplos:

Ejemplo 1.

El product owner se reúne con el encargado de UX y se determina cambiar cierta estructura de un modal en una pantalla equis. ¿Quién debe notificar a los desarrolladores sobre el cambio? ¿Quién debe notificar a las áreas de calidad sobre este cambio? si el modal ya pasó por QA el impacto es aún mayor.  ¿debíamos incluir al área de desarrollo y calidad en esta reunión? ¿el hecho de haber estado presentes en la discusión sobre el cambio que impacto tendría en su capacity?

 

Ejemplo 2:

Llegamos a una planning con una hoja en blanco, nuestras historias de usuario no tienen un ningún criterio de aceptación, descripción, casos de uso, etc. Solo cuentan con un titulo general sobre lo que se debe hacer. ¿Qué tan profundo puede ser el comprendimiento de las áreas de desarrollo, ux y QA sobre lo que se debe construir? ¿Cuánto tarda el equipo realizando consultas intentando clarificar una idea propia, por tanto, subjetiva sobre los que se requiere? ¿Puede el QA planificar las pruebas bajo una construcción ágil si no tiene idea sobre los criterios mínimos? Y finalmente ¿Cuándo tiempo dura esta planning? ¿Cuánto le cuesta al negocio en HH? ¿Cuánto interrumpe el avance de las actividades de los miembros del equipo?

Un tema siempre recurrente en equipos ágiles son estos “corto circuitos comunicacionales” entre las diferentes áreas involucradas, producidos irónicamente por la idea general (y real) de que se realizan muchas reuniones, lo que implica que se tiende a evitar incluir a las áreas técnicas en muchas otras reuniones, produciendo escenarios como el siguiente (que pasó en realidad):

–  El Product Owner(PO) notifica a los desarrolladores de front que campo de mail debe aceptar hasta 50 caracteres. Front procede y aumenta el limite que estaba en 30, Esta definición no fue informada a QA (ni siquiera había criterios sobre el largo del mail), por tanto, en las casuísticas la regla seguía siendo 30 caracteres máximo en el mail y no se incluían pruebas de borde sobre ese número. Al salir a producción se originan errores en el registro de usuarios, no en el front si no un error desconocido en los servicios. El debug lleva un tiempo y se determina que los servicios (que conectan el back con el front) no fueron actualizados y solo aceptan 30 caracteres, se soluciona, pero el error continuó. Finalmente, tras muchas horas de afectación al cliente, se determina que el problema se replica a nival de BD donde el campo mail tiene un limite de 30 caracteres.

Este es un caso (repito nuevamente, real) que se podría haber evitado no necesariamente incluyendo a todas las áreas en una extensa reunión donde el 90% del tiempo fue una conversación entre el PO y el UX, si no distribuyendo la información apropiadamente.

Y es que este es el meollo del asunto; la construcción de una estrategia para distribuir la información horizontalmente de forma efectiva.

 

Una propuesta interesante para solucionar este problema es la implementación de un log simple de actividades diarias, este “log” debe incluir definiciones relevantes realizadas durante el día, incidentes o información crítica de algún otro aspecto. Como regla cada punto no debe superar dos renglones y debe ser leído por los miembros del equipo previo a cada daily. Idealmente se debiese consultar si existe alguna duda con respecto a lo allí planteado para profundizar en los puntos necesarios con quienes así lo necesiten, ej:

–          Se ha informado que el campo mail en la BD solo acepta 30 caracteres. (FF)(HU xxx)

–          UX realizará un cambio en el login, hablado con…. (AA)

–          El equipo “equis” debe enviarnos los contratos de sus servicios rest el día xx/xx a más tardar

En este ejemplo ultra simple, se notifica información relevante para todo el equipo, evitando los cortocircuitos informativos y el exceso de reuniones para su obtención.

El problema de comunicación en equipos ágiles es un tema relevante en las dinámicas organizacionales y el presente artículo, más que un seudo intento de guía, busca visibilizar un problema actual, problema cuya soluciona puede brindar muchos beneficios tanto para el negocio (en términos de ahorros) como para el ambiente laboral.