Agilidad en equipos multi-localizados

por Alejandro Verdú - Agile Coaching Team Leader Sopra Steria España
por Jose Drac - Director Centro de Servicios Digital
| minutos de lectura

Hemos pasado de tener una perspectiva centralizada del trabajo, con una sede en cliente o en nuestro propio edificio que albergaba a los equipos, a una multi-localización que implica, por el contrario, descentralización y dispersión. Esto ha ocurrido de golpe y hay empresas que no estaban completamente preparadas para asumir el reto.

Esta realidad ha generado una resistencia del management más tradicionalista, por percibirlo como una pérdida de poder. “Ya no puedo tutelar en primera persona a mis equipos, ya no puedo estar encima cada minuto”. Al primer signo de dificultad en el despliegue de un modelo multi-localizado rápidamente se abrazaban a frases defensivas tipo “ya te lo dije, no iba a funcionar”, acompañadas de una sonrisita de orgullo.

No obstante, los hechos han sido claros. Durante la pandemia, los que trabajan a distancia y siguen practicando agilidad han podido demostrar los beneficios de estos enfoques. Y eso es, precisamente, lo que vamos a ver hoy aquí.

Pero antes de entrar en el meollo del asunto, tenemos que aclarar que ésta será una publicación enfocada en temas pragmáticos y no tanto en la teoría. No se incidirá en lo necesario para ejecutar agile, cómo se gestiona el producto o cómo establecer modelos de ejecución, sino que hablaremos de cómo la multi-localización puede formar parte de los equipos en agilidad. 

 

Remote first. Un cambio de enfoque

La multi-localización posibilita sacar partido de algunas situaciones a las que, de otro modo, sería más difícil acceder. En primer lugar, podemos entrar en lugares y mercados con menor saturación de demanda (incorporando talento infrautilizado, fomentando la movilidad y la promoción y reduciendo los costes).Sin embargo, si no se ejecuta correctamente, puede haber ineficiencias y los equipos pueden frustrarse.

Por eso, para llevar a cabo estos proyectos de modo exitoso, hemos de cambiar el enfoque. No basta con añadir plugins y funcionalidades nuevas, sino que hemos de mantener el espíritu de un solo equipo que interactúa para aportar valor al usuario, es decir, hay que mantener el enfoque de agilidad, pero partiendo de la distancia. De este modo, evitaremos equipos muy alineados, pero con baja autonomía (lo que provoca una línea autoritaria, pero conformista y sin perfiles capaces de aportar valor) y equipos muy autónomos, pero con poca alineación (en los que nadie sabe en qué trabajan los demás).La forma más eficiente de hacerlo es crear un equipo indivisible, aun multi-localizado.

Este enfoque implica, además, incorporar la mejora continua dentro de nuestro backlog. La deuda técnica y los comportamientos ineficientes, en comunicación, por ejemplo, a veces son poco reconocibles, pero pueden llegar a derrotarnos. Si detectamos un déficit de funcionamiento no podemos pensar que es una tarea de fondo, sino que hay que explicitarlo. Si hiciéramos una analogía con el framework de agilidad en escala SAFe, diríamos que se trata de un Enabler (habilitador), un elemento a añadir al backlog y al que alguien tendrá que dedicarle su esfuerzo. 

 

Modelos de multi-localización

Cuando hablamos de multi-localización, no nos referimos únicamente al trabajo en las oficinas o fuera de ellas, sino que existen distintos tipos y dinámicas de multi-localización más o menos útiles según el contexto del proyecto.

La co-localizacion es el más habitual, pero también existen modelos multisite, con distintos clusters en oficinas separadas; satélite, donde hay un cluster central y una serie de individuos en localizaciones en las que hay gente de valor; o en nebulosa, en el que se pasa de estar distribuidos a estar dispersados. Todas estas dinámicas se han visto favorecidas a raíz de la mejora de las comunicaciones y el auge de los nuevos modelos de trabajo.

 

Sin embargo, la ejecución de cada uno de ellos debe llevarse a cabo de forma adecuada, para no caer en malas implementaciones. Como ejemplos, podemos mencionar el cluster tirano, que actúa igual que si no hubiera nadie en distancia, sin ponerse en la piel de quiénes se conectan desde otros lugares, o la nebulosa en la misma mesa, donde estamos todos en la oficina, planta o mesa, pero cada uno en su ordenador, sin espacios de interacción híbridos, adaptados a contextos de personas en salas de reunión + personas en conexiones individuales. Esta última implementación es aceptable ahora debido a la situación de pandemia (distancia social), pero normalmente debe evitarse.

 

Dímelo a la cara

La mayoría de frameworks ágiles establecen la necesidad de fijar una cuota de integrantes por equipo. Esto es así porque, al hablar con una persona establecemos líneas de comunicación que van aumentando en número y complejidad conforme se incluyen nuevos miembros. El hecho de trabajar en remoto, además, añade ruido adicional.

 

Esto, unido a la ‘reunionitis’ que ha llevado aparejado el teletrabajo, provoca una sensación de falta de productividad que, en realidad, no es otra cosa que una mala gestión de la multi-localización debido a una necesidad excesiva de control y falta de organización.

Aunque las reuniones son necesarias para asuntos complejos, urgentes o que requieren de empatía (es importante que los participantes se vean las caras), hemos de reconocer que suponen un cambio de contexto. Así, pese a que agile favorece la sincronía, también hay un margen saludable para hablar de asincronía. 

 

Automatismos y automatización

En un entorno Agile en multi-localización, debemos estructurar la información de manera lean, de modo que sea precisa, compartida, actualizada y disponible… y automatizar.

Todos estos marcos de trabajo extendidos implican orientarse hacia un mindset apoyado en la tecnología. Para aportar valor hay que industrializar el flujo y, como siempre en Agile, validar su buen funcionamiento de forma muy temprana, lo antes posible.

Hablamos de introducir herramientas que permitan mejorar la visibilidad de modelos adaptativos basados en iteraciones cortas. Necesitas datos, y para conseguir datos, hay que automatizar. Solo así podrás visualizar la información rápidamente sin generar intercambios innecesarios que generan nuevos flujos de comunicación. Una vez más hay que aislarse de construir líneas artificiales de comunicación por no haber sido capaces de aprovechar ventajas tecnológicas que permiten acortar la distancia.

 

El contenido de este artículo ha sido extraído del webinar 'Agilidad en equipos multi-localizados' de la serie Smart Talks, por parte de José Drac y Alejandro Verdú. Si no pudiste asistir, puedes visualizarlo aquí.

Search

agile

Contenidos relacionados

Cinco pequeños agilistas: una historia basada en hechos reales

La desconfianza que suscita la autoorganización entre el management es un caballo de batalla con el que los agilistas nos encontramos casi cada día.  

Historia de un padre ‘agilista’ en apuros: combatiendo el confinamiento con Kanban

El excepcional momento que estamos viviendo provoca situaciones nuevas a las que tenemos que enfrentarnos y, como cualquier caso que nos saque de nuestra zona de confort, da pie a estar más despiertos y a innovar para sacar adelante los retos que se nos presentan. 

¿Hay otra forma de gestionar productos de modo ágil?

¿Cómo podemos gestionar de una manera diferente las posibles desviaciones sobre un plan que hemos trazado al principio de un proyecto? Para responder a esta pregunta, hay que hablar de la gestión basada en evidencias.