Quizá has oido esto mucho cuando, por determinadas circunstancias, se han juntado equipos en distintos puntos de madurez. Las comparaciones son siempre odiosas, y cuando comparas equipos, mucho más.

Cuando esto lo sumas a que estos distintos equipos están envueltos es una transformación global en una empresa, es peor aún. Lo que se acaba comparando son simplemente procedimientos o formas de trabajo concretas y a partir de esta comparación, algunas personas pueden catalogar a otros equipos como no-agile. Las razones suelen ser tán superficiales como que aún no han incorporado tal o cual practica ágil.

Si por ejemplo, juntamos un equipo que sí realiza ATDD (definición de los tests de aceptación antes del desarrollo) y otro equipo en el aún no lo hacen y los tests los realizan cuando el desarrollador ha terminado su parte, puede ocurrir que a estos últimos se les acuse con ¡Eso no es Agile, waterfallista!. Sin embargo, en mi opinión, el hacer esto es debido a tener una visión muy sesgada de lo que es un proceso de maduración Ágil del equipo. En este ejemplo, sólo se tiene en cuenta el QA y el equipo que realiza ATDD se considera que hace Agile y el que no, es un mero Waterfallista.

Cuando digo sesgada me refiero a que esta acusación tambien podría pasar desde el punto de vista de despliegue del producto. Si juntamos un equipo que hace integración continua y pone en producción cada historia que se va terminando y a otro equipo en el que sencillamente el despliegue se hace después de haber terminado el sprint, el primer equipo podría decir al otro «. ¡Eso no es Agile, waterfallista!

O lo mismo puede ocurrir desde el punto de vista de diseño. Si en esta ocasión juntamos un equipo en el que hay miembros que realizan el diseño como una tarea más a la vez que la codificación con otro equipo en el que el diseño se hace un sprint anterior, puede llegar el listo de turno y decirles a estos últimos ¡Eso no es Agile, waterfallista!

Entonces ¿Qué es hacer Agile o no? Si habeis trabajado con un buen agilista, lo más probable es que este tipo de cosas no hayan salido nunca por su boca. Nos guardamos mucho de catalogar una forma de trabajo como Agile o No-Agile. Entendemos que cada equipo está en una fase de maduración distinta e historicamente se puede haber enfocado en mejorar una serie de practicas sobre otras, para solucionar unos problemas que para ellos eran más prioritarios que otros.

Agile no es más ni menos que el tener presente una serie de valores y principios marcados en su manifiesto. No hay un modo de trabajo que se pueda catalogar como más Agile que otro. De hecho, seguramente se puede hacer un trabajo puro waterfall por fases (analisis, diseño, desarollo, qa, despliegue) y ser Agil al mismo tiempo: haber dado más importancia a las personas y a sus interacciones, también al generar sofware más que a la documentación exhaustiva, se ha colaborado de principio a fin con el cliente y no se ha seguido el plan a fe ciega sin tener en cuenta el contexto. Entiendo que los valores hacen mucho challenge de las problemas que genera el seguir a pies juntillas el sistema waterfall, pero este escenario podría ocurrir. Una serie de practicas concretas no identifican un equipo como Agile o no

Consejo: cuando evalues o compares equipos, evita categorizarlos. Cada equipo tiene su propia historia y sus razones de trabajar de un modo en particular. Si quieres ayudarles, enfócate a entender esas razones y sus problemas reales. A partir de esos problemas, es donde vamos a poder recomendarles una u otra práctica. Si no, mira hacia atrás y hazte la pregunta «¿Nosotros empezamos a ser Ágiles solamente desde que empezamos a hacer algo en concreto o sencillamente desde que nos planteamos empezar esta transformación?»