Evolución de Agilidad técnica: Mejorando la eficiencia del flujo de trabajo y la entrega de valor
La trampa de Mini-Waterfall en Equipos Agiles
A lo largo de mis años de carrera he podido identificar un patrón que se repite una y otra vez en equipos Agiles que usan Scrum o algún escalado derivado. Tal vez lo hayan escuchado como “mini-cascada”. Este trabajo secuencial similar a la cascada se puede identificar a través de varios síntomas:
- Los miembros del equipo se refieren a otros miembros como “el equipo de…”.
- Se escuchan frases como “estoy esperando por el equipo de…” o “ya terminé mi tarea”.
- Los acuerdos no se cumplen. Hay poco sentido de “urgencia”.
- El equipo tiene carry over sistemáticamente.
Si bien podemos ver varias disfunciones en este comportamiento, esto puede desembocar en problemas (tal vez más graves) como la terminación del producto (o peor, del equipo). Esto se termina dando por diferentes razones: el producto no gusta, tiene errores, es caro, etc.
Business Value en Agile Delivery
Cuando trabajamos en un equipo Agile debemos recordar el Manifesto:
Nuestra mayor prioridad es satisfacer al cliente
mediante la entrega temprana y continua de software
con valor.
Pero, ¿qué quiere decir esto y cómo gano dinero yo con esta frase? Traducido a términos de negocio, debemos recordar lo que nos une: encontrar una solución innovadora a un problema real. Es decir, estamos creando un producto o servicio que satisfaga una necesidad, pero esto parte desde nuestra mirada, la cual puede estar sesgada, y por ende es necesario validar que esa mirada es la correcta. Yendo un poco más lejos, vivimos en un mundo ampliamente competitivo y hay muchas chances de que haya alguien más haciendo lo mismo. Entonces, ¿cómo puedo competir contra millones de desarrolladores en el mundo pensando ideas similares?
Eficiencia y Time-to-Market
Una ventaja competitiva puede verse a través del “time to market” (TTM). Este tiempo es una de las variables que nos ayuda a entender qué tan capaces somos de reaccionar a partir de observar una oportunidad.
Para lograr un TTM competitivo empezaremos a trabajar por donde mejor se nos da: en la Agilidad de Equipos. En particular vamos a enfocarnos en mejorar la eficiencia del flujo de trabajo. Para esto vamos a usar tres medidas: Cycle Time (la medida de cada paso en el flujo), los tiempos de espera y la suma (Lead Time). El flujo de eficiencia lo mediremos como la relación entre el tiempo activo (suma de cycle time) sobre el lead time (ver: https://scaledagileframework.com/measure-and-grow/).
Eficiencia de flujo
Volviendo al problema inicial: el patrón de mini-cascada dentro de cada Scrum Sprint, ¿te imaginas cuál puede ser la eficiencia de un flujo de trabajo en cascada?. Hay que tener en cuenta el tiempo activo, las esperas, las idas y vueltas, se hace mucho tiempo, algo muy poco eficiente. ¿Qué sería intuitivo para mejorar este flujo?… lo primero que se nos puede venir a la mente es: reducir esperas. Esto seguramente puede ayudar, y para eso debemos estar alineados y preparados para recibir trabajo, ¿pero qué hacemos mientras esperamos?… Se me ocurre otra idea: paralelizar trabajo con sincronización y coordinación extrema.
Veamos los siguientes principios:
Los responsables de negocio y los desarrolladores
trabajamos juntos de forma cotidiana durante todo
el proyecto.El método más eficiente y efectivo de comunicar
información al equipo de desarrollo y entre sus
miembros es la conversación cara a cara.Los procesos Ágiles promueven el desarrollo
sostenible. Los promotores, desarrolladores y usuarios
debemos ser capaces de mantener un ritmo constante
de forma indefinida.La atención continua a la excelencia técnica y al
buen diseño mejora la Agilidad.
Y no olvidemos este:
El software funcionando es la medida principal de
progreso.
Ahora, ¿cómo logramos todo esto? No hay una receta, recordemos que cuando estamos en entornos complejos no hay buenas prácticas, sino soluciones emergentes. Sin embargo, la experiencia nos da algunos indicios de por donde empezar.
Evolución de Agilidad técnica
Empecemos entonces por generar un espacio donde sea posible el trabajo coordinado, sincronizado y al mismo tiempo. Empecemos entonces por agilidad técnica, donde el equipo Agile pueda entregar un producto de calidad, con valor y de forma contínua. Esto sumado a la definición de Scrum, nos lleva a la necesidad de entregar un incremento potencialmente desplegable en cada Sprint.
¿Cómo pasamos de mini-cascada a un equipo de alta performance?
Esto es algo que vi en otros equipos como un patrón que se fue repitiendo, evolución de agilidad técnica:
- Trabajo secuencial: Los equipos trabajan de forma secuencial, existen especialidades o sub-equipos, poco trabajo en equipo, existen atrasos y cuellos de botella. Es entonces que el equipo decide mitigar este problema a través del trabajo en sincronía, estableciendo acuerdos y definiendo una forma de trabajo más interactiva.
- Trabajo coordinado: Como consecuencia, el equipo estabiliza y gana velocidad con el tiempo. Esto provoca que aumente la productividad, y con ella vuelven los cuellos de botella. En este caso se decide comenzar a trabajar codo a codo entre todos los miembros del equipo alrededor de una User Story (en general Devs y QA). En esta nueva forma de trabajo todo el equipo se junta a diseñar y desarrollar casos de prueba, estrategias y arquitectura, de esta forma todas las partes tienen lo que necesitan para reducir las idas y vueltas. Un paso intermedio entre 1 y 2 es cuando los desarrolladores están especializados, algo que suele pasar es que empiezan a tomar roles más Full-Stack.
- Trabajo auto-organizado, eficiente y habilitador: De nuevo, como consecuencia de la velocidad que gana el equipo se vuelven a generar cuellos de botellas por sobrecarga de trabajo, aquí se decide automatizar lo más posible. Es aquí que el rol de QA pasa a ser un rol más consultivo que vigila la calidad integral, más que un ejecutor de pruebas manuales. Se terminan de consolidar perfiles del tipo T-Shapped.
En esta evolución el equipo gana nuevas habilidades, hacen el producto más competitivo, toman más “ownership” del mismo, las ausencias dejan de ser un problema y se puede detectar problemas en etápas tempranas del desarrollo gracias a la automatización.
Algunas preguntas que pueden disparar conversaciones poderosas:
- ¿Tiene dependencias?
- ¿Cómo la van a testear?
- ¿Cuánto se puede automatizar?
- ¿Qué necesita frontend de backend?
Conclusiones
Es importante recordar durante el ciclo de vida de nuestro producto la necesidad de entregar software con valor de forma temprana y continua. he podido identificar un patrón común en equipos que usan Scrum o algún escalado derivado, llamado usualmente como “mini-cascada”. Como Agilistas debemos intervenir a través de medidas que ayuden a mejorar la eficiencia del flujo de trabajo, como el ciclo de tiempo y tiempos de espera. Vemos además una forma de evolucionar equipos que trabajan de forma secuencial a equipos de alta performance que trabajan en sincronía y de forma interactiva, lo que aumenta la productividad y reduce los cuellos de botella.
En definitiva, este artículo busca dejar una reflexión para quienes trabajan en equipos ágiles y buscan mejorar su eficiencia y productividad.
Aclaración: Bajo ningún concepto esto es un plug n’ play, es una sugerencia para probar ante los síntomas antes descriptos, sin embargo, este cambio requiere tiempo y esfuerzo, por lo que generar alineación de todas las partes y acompañar el proceso de transformación es imprescindible.
