Agilidad en equipos XL: Claves para un delivery exitoso

Por: Carlos Medina y Yohan Paez

En el dinámico entorno de productos digitales, siempre se ha hecho hincapié en que el tamaño de un equipo ágil no debe superar cierto número de personas. En la medida que un equipo crece en tamaño, la comunicación y coordinación se complica, por lo que gestionar equipos grandes presenta desafíos únicos y muchas veces resulta inviable hacerlo, pero ¿qué podemos hacer si estamos trabajando con un equipo que ha crecido considerablemente en tamaño y para el cual no es una opción dividir en equipos más pequeños? En este artículo, te contamos nuestra experiencia reciente con un cliente que contaba con un gran equipo de desarrollo y en el que pudimos apoyarnos en prácticas como la toma de decisiones basada en datos, la creación de un espacio seguro, la definición de acuerdos de trabajo y la delegación para lograr un delivery exitoso.

Apoyamos a una startup que ofrecía servicios de billetera digital a través de una aplicación móvil. Un aumento de las transacciones puso a prueba la arquitectura existente, lo que la llevó a tomar la decisión de una migración completa a una nueva plataforma nativa. Este cambio planteó grandes retos debido a la escasa madurez tecnológica de la organización, que requirió capacitación y contrataciones intensivas. La principal consecuencia fue el crecimiento del equipo. Eventualmente el equipo llegó a tener 46 personas.

La gestión de un equipo de estas magnitudes resultó todo un reto, y los responsables del cliente, preocupados por posibles retrasos y perder visibilidad de riesgos y avances, consideraron poco viable dividirlo.

Esto nos llevó a enfrentar varios retos como: priorizar las funcionalidades de la migración para obtener el máximo valor, mejorar la coordinación y la comunicación en un equipo indivisible, garantizar la transparencia sobre las repercusiones y los riesgos de las decisiones, elaborar estrategias para cumplir los plazos acordados y fomentar la seguridad psicológica en medio de las dificultades de comunicación.

Nuestro enfoque

Dentro del enfoque tomado para apoyar al equipo en la migración, la matriz de impacto y esfuerzo desempeñó un papel crucial en la priorización de tareas del extenso backlog que acumulaba el proyecto y con el cual no iba a ser posible llegar a las fechas comprometidas. Esta herramienta se convirtió en un componente esencial para optimizar la gestión de recursos y asegurar que los esfuerzos del equipo se dirigieran hacia áreas de alto impacto, mientras definimos estrategias para las otras tareas.

Implementación práctica:

• Se identificaron las tareas pendientes por implementar dentro de la migración, señalando claramente el dominio dentro de la app y visibilizando todos sus bloqueos.
• Cada tarea fue evaluada en términos de impacto y esfuerzo. El impacto se midió por su contribución al flujo de la app y a la experiencia de usuario, mientras que el esfuerzo abordó la complejidad técnica de cada tarea, el número de dependencias y la incertidumbre asociada.
• Las tareas se analizaron en base a su impacto y esfuerzo, y se agregaron puntuaciones para compararlas relativamente y poder ubicarlas en los ejes de la matriz.
• Se priorizaron aquellas tareas con alto impacto y bajo esfuerzo, seguidas de aquellas con alto impacto y alto esfuerzo. En el caso de dependencias e incertidumbre, se mantuvieron discusiones para ir levantando cualquier bloqueo. Aquellas tareas con bajo impacto se reservaron para un análisis posterior.

Beneficios en la estrategia

1. Focalización de recursos:

Con un equipo tan grande, había una tendencia a emprender tareas en el backlog que carecían de valor de negocio, a pesar de su atractivo técnico. Reorganizamos el trabajo categorizando las tareas, agilizando el proceso para todos los desarrolladores en cada sprint y revisándolo continuamente.

2. Decisiones informadas:

La matriz facilitó la toma de decisiones basada en datos al revelar la relación entre el valor de la tarea y el esfuerzo. También identificaba y abordaba los cuellos de botella críticos antes de que los desarrolladores se ocuparan de las tareas.

Acuerdos de equipo

Al gestionar un equipo grande e indivisible que trabajaba en la misma base de código, los acuerdos claros del equipo eran cruciales para mejorar la coordinación y la comunicación. Para hacer frente a los retos de alineación, asignación de tareas y visibilidad, establecimos acuerdos compartidos. Éstos no sólo fijaban expectativas comunes, sino que también servían de marco para una colaboración y una toma de decisiones eficaces.

• Definición de Listo y Hecho: Establecimiento de criterios para los elementos del backlog tras las sesiones de equipo para determinar la preparación y finalización del desarrollo.
• Comunicación transparente: Se establecieron protocolos para una comunicación clara y programada del equipo, especificando canales, propósitos, participantes y recursos compartidos.
• Ceremonias: Gestionamos el reto de un equipo grande manteniendo las ceremonias breves. La sincronización diaria (daily stand up) se centró en desbloquear y difundir información clave, mientras que las reuniones más grandes, como las retrospectivas, se racionalizaron en sesiones de grupos pequeños con acuerdos finales consolidados.
• Límite de trabajo en curso (WIP): se acordó asignar una tarjeta de función no bloqueada por desarrollador para mejorar la eficiencia del flujo, reducir los tiempos de espera y clarificar la propiedad de las tareas en la junta.
• Estandarización del flujo de trabajo: Se definieron las etapas y criterios para varios tipos de tareas, garantizando que las tareas cumplían condiciones específicas para avanzar o retroceder por etapas dentro del tablero Kanban.
• Puntos focales por área de dominio: Se definieron personas de contacto por cada una de las áreas de dominio de la app. Aunque el conocimiento era compartido, estas personas eran expertas en su área de dominio y apoyaban al resto del equipo.
• Priorización de sprints: El gestor de producto y los puntos focales del área de dominio debatían y validaban las prioridades de cada sprint apoyándose en la matriz de impacto y esfuerzo. A continuación, los desarrolladores coordinaban la asignación de tareas para cada sprint.
• Mejora continua: Fomentando una cultura de mejora continua, se animó a todos los miembros del equipo a sugerir optimizaciones de eficiencia y calidad. En cada sprint se celebraba una sesión en la que participaba todo el equipo para revisar estas propuestas y los acuerdos tomados en retrospectivas anteriores.

Gobernanza del equipo basada en datos

La implementación de un modelo de gobierno ágil basado en datos fue esencial para gestionar el equipo de manera efectiva, fomentando la agilidad, la transparencia y la toma de decisiones informada. El modelo utilizado se basó en varios pilares:

• Identificación y seguimiento de riesgos, supuestos, problemas y dependencias (RAID): Periódicamente se revisaba un tablero donde se registraban todos los RAID del proyecto de migración, se discutían planes de mitigación y se hacía un track de todas las acciones llevadas a cabo desde la sesión anterior.
• Métricas de kanban como indicador del rendimiento del equipo: Se observaban constantemente las métricas asociadas al tablero kanban, específicamente las que se refieren a throughput, cycle time, lead time, edad de los ítems y eficiencia de flujo. La revisión periódica de estas métricas permitía identificar cuellos de botella y oportunidades de mejora al flujo de trabajo. Incluso mediante el análisis del throughput fue posible demostrar lo insostenible de seguir agregando personas al equipo. Además, la estabilidad del ritmo de entrega, junto con un slicing adecuado de las tareas, fue permitiendo alcanzar un modelo ágil basado en entrega de valor y no en estimaciones (no estimates).

Monitoreo de four key metrics para evaluar el proceso de desarrollo y despliegue. Se implementaron las four key metrics:

• Lead time
• Deployment Frequency
• Change Failure Rate
• Mean Time To Recovery

Y se fueron analizando constantemente, para identificar oportunidades de mejora en el proceso de desarrollo y despliegue de la aplicación. Estas mejoras, a su vez, se tradujeron en cambios en el flujo de trabajo o en acuerdos con otros equipos, como por ejemplo el equipo Devops.

• Simulaciones de Montecarlo para estimar fechas: Con el enfoque no estimates, fue posible utilizar la tendencia de datos con la que se contaba para estimar posibles fechas en las que el equipo completaría las tareas del backlog.

Uso de Montecarlo y análisis Impacto vs Esfuerzo para reducir el alcance

Con los acuerdos de equipo, la gobernanza en datos y la revisión del backlog, se sentaron las bases para que el equipo, aun con su gran tamaño, pudiera trabajar de manera coordinada y en conjunto. Sin embargo, había un problema crítico: Se acercaba la fecha tope y aún había muchas tareas por completar.

Ante la imposibilidad de mover la fecha y de ampliar el equipo, resultaba inminente cambiar el alcance de la migración. La simulación de Montecarlo fue una herramienta clave para este análisis. Esta nos permitió modelar distintos escenarios y plantear las decisiones que se podrían tomar para cumplir con el plazo previsto.

Por ejemplo, con el análisis de impacto y esfuerzo, fue posible identificar tareas que fácilmente podían sacarse del alcance del equipo, pues aunque su impacto en el negocio era medio, requerían poco esfuerzo y, en especial, poco conocimiento del flujo de la app. Tal era el caso de tareas como monitoreo de rendimiento, implementación de librerías para medir el performance, implementación de tags para análisis de datos, herramientas para comprender el comportamiento del usuario, entre otras.

Se modelaron distintos escenarios, entre los que el más favorable fue uno en el que un equipo temporal se encargaba de desarrollar las tareas de bajo esfuerzo e impacto, y otro equipo (también temporal), se concentraba en cerrar todos los bugs detectados, todo esto en paralelo al equipo de migración, que estaba concentrado en resolver las tareas priorizadas por área de dominio. Al adoptar este enfoque, se logró mantener el foco de gran parte del equipo en la migración y que otro equipo fuera tomando puntos que eran clave para la gestión interna pero no para el usuario.

La importancia de la seguridad psicológica

La seguridad psicológica, crucial para el éxito del proyecto, se enfrentaba a retos en un equipo grande con canales de comunicación limitados. Para solucionarlo, formamos pequeños grupos: equipos transversales (QA, UX, BA), equipos funcionales y coordinamos sesiones entre líderes y puntos focales. Las actividades de creación de equipos en pequeños grupos rotatorios se centraron en la comunicación eficaz, la retroalimentación, el reconocimiento, la diversidad, la gestión de conflictos y la creación de relaciones.

Para preservar la seguridad psicológica, las encuestas periódicas de clima medían la salud del equipo, evaluando el NPS, la carga de trabajo, la autonomía, la retroalimentación, los logros y el aprendizaje. Analizando estos valores, se definieron estrategias de mejora en periodos posteriores.

El resultado

Finalmente, el objetivo se logró, se pudo culminar la migración en el plazo acordado, y la madurez técnica del equipo, junto con las buenas prácticas seguidas durante todo el proceso, hicieron que el impacto a los usuarios finales del cambio de arquitectura fuera mínimo. La cantidad de bugs reportada fue muy baja y el tiempo de respuesta se mantuvo bastante corto. Además, la integración continua permitió liberar nuevas versiones en tiempo récord, reduciendo el time to market y causando un aumento del NPS de la app. Finalmente, las personas que eran parte del equipo, fueron enviadas a las distintas áreas de dominio a apoyarlas en la adopción de la nueva arquitectura y prácticas de ingeniería.

Conclusiones

1. Migrar una aplicación de gran impacto a una nueva arquitectura plantea retos, especialmente con la necesidad de nuevas capacidades técnicas y una madurez tecnológica limitada. Las limitaciones de tiempo se intensifican por el deseo de que el impacto en el usuario sea mínimo, lo que exige transparencia en el alcance y los riesgos.
2. La Matriz de Impacto y Esfuerzo, junto con las simulaciones Monte Carlo, resultaron cruciales para gestionar el trabajo pendiente y optimizar la asignación de recursos. La priorización de tareas en función del impacto y el esfuerzo centró los esfuerzos en áreas de gran valor, garantizando el éxito de la migración.
3. El establecimiento de acuerdos de equipo abordó los retos de coordinación derivados del tamaño del equipo, cubriendo funciones, criterios de trabajo listo y terminado, comunicación transparente y gestión ceremonial. Hacer hincapié en la importancia de estos acuerdos y confiar en el liderazgo de los subgrupos facilitó la implementación.
4. La adopción de un modelo de gobernanza basado en datos, que incluía el seguimiento de RAID, métricas Kanban y cuatro métricas clave, permitió al cliente tomar decisiones con conocimiento de causa. La identificación de riesgos y la mejora continua de los procesos fueron resultados clave.
5. En un equipo numeroso, el fomento de la seguridad psicológica era primordial. Las actividades de creación de equipos, la rotación de grupos, la comunicación eficaz y la gestión de conflictos contribuyeron a mantener un entorno seguro y comprometido.

¿Quieres formar parte de Thoughtworks? Aplica a nuestras vacantes en nuestra página web https://thght.works/3F3T4JA